Re: hot_standby_feedback doesn't work on busy servers in 9.3+

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: hot_standby_feedback doesn't work on busy servers in 9.3+
Date: 2014-01-16 21:24:13
Message-ID: 52D84DFD.3040503@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2014-01-16 21:55:10 Re: hot_standby_feedback doesn't work on busy servers in 9.3+
Previous Message Heikki Linnakangas 2014-01-16 21:14:17 Re: hot_standby_feedback doesn't work on busy servers in 9.3+