From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Standby catch up state change |
Date: | 2013-10-15 11:21:54 |
Message-ID: | 20131015112154.GF5300@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-10-15 16:29:47 +0530, Pavan Deolasee wrote:
> On Tue, Oct 15, 2013 at 4:16 PM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:
>
> > I don't think delaying the message is a good
> > idea.
>
>
> Comment in walsender.c says:
>
> /*
> * If we're in catchup state, move to streaming. This is an
> * important state change for users to know about, since before
> * this point data loss might occur if the primary dies and we
> * need to failover to the standby.
> */
>
> IOW it claims no data loss will occur after this point. But if the WAL is
> cached on the master side, isn't this a false claim i.e. the data loss can
> still occur even after master outputs the log message and changes the state
> to streaming. Or am I still getting it wrong ?
I think you're over-intrepreting it. We don't actually rely on the data
being confirmed received anywhere. And the message doesn't say anything
about everything safely being written out.
So, if you want to adjust that comment, go for it, but I am pretty
firmly confirmed that this isn't worth changing logic.
Note that the ready_to_stop logic *does* make sure everything's flushed.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2013-10-15 11:35:26 | Re: SSL renegotiation |
Previous Message | Pavan Deolasee | 2013-10-15 10:59:47 | Re: Standby catch up state change |