Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Date
Msg-id CA+TgmoYo8m-uK6Qti29Fs2C=56XbJw6n35OZUQOUePfKKP9sCg@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown  (Amit Kapila <amit.kapila@huawei.com>)
List pgsql-hackers
On Mon, Oct 8, 2012 at 10:42 AM, Amit Kapila <amit.kapila@huawei.com> wrote:
> How about following:
> 1. replication_client_timeout -- shouldn't it be client as new configuration
> is for wal receiver
> 2. replication_standby_timeout

ISTM that the client and the standby are the same thing.

> If we introduce a new parameter for wal receiver, wouldn't
> replication_timeout be confusing for user?

Maybe.  I actually don't think that I understand what problem we're
trying to solve here.  If the connection between the master and the
standby is lost, shouldn't the standby realize that it's no longer
receiving keepalives from the master and terminate the connection?  I
thought I had tested this at some point and it was working, so either
it's subsequently gotten broken again or the scenario you're talking
about is different in some way that I don't currently understand.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PQntuples and PQgetvalue problem.
Next
From: Robert Haas
Date:
Subject: Re: Placement of permissions checks for large object operations