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:27:51 |
Message-ID: | AANLkTil0gaKqJjqpoyBlSD3dZnUETQM35updVcfmMQk_@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 3, 2010 at 4:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> On Thu, Jun 3, 2010 at 12:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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?
>
> Well, if the slave can't keep up, that's a separate problem. It will
> not fail to keep up as a result of the transmission mechanism.
No, I mean if the slave is paused due to a conflict. Does it stop
reading data from the master or does it buffer it up on disk? If it
stops reading it from the master then the effect is the same as if the
slave stopped "requesting" data even if there's no actual request.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-06-03 15:28:49 | Re: functional call named notation clashes with SQL feature |
Previous Message | Tom Lane | 2010-06-03 15:26:07 | Re: "caught_up" status in walsender |