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
|
Список | 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 по дате отправления: