From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-03 15:07:10 |
Message-ID: | AANLkTikmXYcu6brR3aqwGxcW6j5I9QhMPo7L7Bkw0kP7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 3, 2010 at 12:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-06-03 15:17:53 | Re: functional call named notation clashes with SQL feature |
Previous Message | Tom Lane | 2010-06-03 14:54:13 | Did we really want to force an initdb in beta2? |