Re: Keepalive for max_standby_delay

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Keepalive for max_standby_delay
Date: 2010-06-02 23:11:08
Message-ID: 13557.1275520268@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-06-02 23:22:51 Re: Idea for getting rid of VACUUM FREEZE on cold pages
Previous Message Greg Stark 2010-06-02 22:59:23 Re: Keepalive for max_standby_delay