On 2014-01-16 23:24:13 +0200, Heikki Linnakangas wrote:
> 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).
If we'd always send a message, I'd be convinced by that argument, but
we're only sending messages after a timeout. This means that if syncrep
is on, we will more frequently have explicitly ask the receiver to send
a confirmation since the reply before the flush will have reset the
timers causing the reply after the flush to only infrequently send
something.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services