Re: Keepalive for max_standby_delay - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Keepalive for max_standby_delay
Date
Msg-id 13557.1275520268@sss.pgh.pa.us
Whole thread Raw
In response to Re: Keepalive for max_standby_delay  (Greg Stark <gsstark@mit.edu>)
Responses Re: Keepalive for max_standby_delay  (Stephen Frost <sfrost@snowman.net>)
Re: Keepalive for max_standby_delay  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> I was assuming the walreceiver only requests more wal in relatively
> small chunks and only when replay has caught up and needs more data. I
> haven't actually read this code so if that assumption is wrong then
> I'm off-base.

It is off-base.  The receiver does not "request" data, the sender is
what determines how much WAL is sent when.

> So I think this isn't necessarily such a blue moon event. As I
> understand it, all it would take is a single long-running report and a
> vacuum or HOT cleanup occurring on the master.

I think this is mostly FUD too.  How often do you see vacuum blocked for
an hour now?  It probably can happen, which is why we need to be able to
kick queries off the locks with max_standby_delay, but it's far from
common.  What we're concerned about here is how long a buffer lock on a
single page is held, not how long heavyweight locks are held.  The
normal hold times are measured in microseconds.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Keepalive for max_standby_delay
Next
From: Bruce Momjian
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages