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