On Fri, Feb 18, 2011 at 7:55 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> So, in summary, the position is that we have a timeout, but that timeout
>> doesn't work in all cases. But it does work in some, so that seems
>> enough for me to say "let's commit". Not committing gives us nothing at
>> all, which is as much use as a chocolate teapot.
> Can someone summarize the cases where it does and doesn't work?
> There's been a longish gap in this thread.
The timeout doesn't work when walsender gets blocked during sending the
WAL because the send buffer has been filled up, I'm afraid. IOW, it doesn't
work when the standby becomes unresponsive while WAL is generated on
the master one after another. Since walsender tries to continue sending the
WAL while the standby is unresponsive, the send buffer gets filled up and
the blocking send function (e.g., pq_flush) blocks the walsender.
OTOH, if the standby becomes unresponsive when there is no workload
which causes WAL, the timeout would work.
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
In response to
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2011-02-18 02:12:29|
|Subject: Re: arrays as pl/perl input arguments [PATCH]|
|Previous:||From: Charles.McDevitt||Date: 2011-02-18 01:01:39|
|Subject: Re: Debian readline/libedit breakage|