Re: Keepalive for max_standby_delay

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Keepalive for max_standby_delay
Дата
Msg-id 13557.1275520268@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Keepalive for max_standby_delay  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Keepalive for max_standby_delay  (Stephen Frost <sfrost@snowman.net>)
Re: Keepalive for max_standby_delay  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Keepalive for max_standby_delay
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Idea for getting rid of VACUUM FREEZE on cold pages