Re: hot_standby_feedback doesn't work on busy servers in 9.3+ - Mailing list pgsql-bugs

From Heikki Linnakangas
Subject Re: hot_standby_feedback doesn't work on busy servers in 9.3+
Date
Msg-id 52D84DFD.3040503@vmware.com
Whole thread Raw
In response to Re: hot_standby_feedback doesn't work on busy servers in 9.3+  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: hot_standby_feedback doesn't work on busy servers in 9.3+
List pgsql-bugs
On 01/16/2014 10:44 AM, Andres Freund wrote:
> On 2014-01-16 10:26:51 +0530, Amit Kapila wrote:
>>> Looking into this I also noticed that the busy path is odd, because a)
>>> why are we sending a reply before flushing things to disk? b)
>>> XLogWalRcvFlush() will do it's own XLogWalRcvSendReply().
>>
>>     I think call to reply in XLogWalRcvFlush() might not actually send
>>     reply because of time difference of last Reply message which we
>>     sent before flush call.
>
> Yes, but most of the time that will lead to only outdated data to be
> sent since that's the first call. Hardly a severe issue, odd nonetheless.
>
>>     The only point that occurs to me for having such a code is that
>>     incase flush call fails due to disk space or some other such issue,
>>     it can atleast send the correct write position to primary.
>
> Unconvinced.

The reply message contains a pointers for how far the WAL has been
applied, written, and flushed. There can be a significant delay between
the write and flush steps, so we send a separate reply after writing,
and after flushing. (if we didn't, the flush and write pointers sent to
the master would always be the equal).

- Heikki

pgsql-bugs by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: hot_standby_feedback doesn't work on busy servers in 9.3+
Next
From: Andres Freund
Date:
Subject: Re: hot_standby_feedback doesn't work on busy servers in 9.3+