Re: Keepalive for max_standby_delay

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Keepalive for max_standby_delay
Дата
Msg-id AANLkTikmXYcu6brR3aqwGxcW6j5I9QhMPo7L7Bkw0kP7@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Keepalive for max_standby_delay  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Keepalive for max_standby_delay  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jun 3, 2010 at 12:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Hm, so what happens if the slave blocks, doesn't the sender block when
the kernel buffers fill up?

>> 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?

No, that's not comparable. On the master vacuum will just ignore
tuples that are still visible to live transactions. On the slave it
doesn't have a choice, it sees the cleanup record and must pause
recovery until those transactions finish.

--
greg


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Did we really want to force an initdb in beta2?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: functional call named notation clashes with SQL feature