Skip site navigation (1) Skip section navigation (2)

Re: Replication server timeout patch

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Replication server timeout patch
Date: 2011-02-18 02:10:46
Message-ID: AANLkTin0YGmAo5cFfEi5v9WX5rGshpZuCZdufeqxoNmz@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-02-18 02:12:29
Subject: Re: arrays as pl/perl input arguments [PATCH]
Previous:From: Charles.McDevittDate: 2011-02-18 01:01:39
Subject: Re: Debian readline/libedit breakage

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group