From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(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-17 13:23:39 |
Message-ID: | 20140117132339.GI30206@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2014-01-17 10:50:29 +0200, Heikki Linnakangas wrote:
> On 01/16/2014 11:55 PM, Andres Freund wrote:
> >On 2014-01-16 23:24:13 +0200, Heikki Linnakangas wrote:
> >>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.
>
> No, XLogWalRcvSendReply also sends the reply if the flush or write pointers
> have advanced since last reply, even if the timeout hasn't expired.
Uh. Yes. I mis-remembered that we weren't doing that, but that's just
the apply value...
Sorry for the noise,
'
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-17 19:36:25 | Re: [HACKERS] surprising to_timestamp behavior |
Previous Message | Heikki Linnakangas | 2014-01-17 08:50:29 | Re: hot_standby_feedback doesn't work on busy servers in 9.3+ |