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

Re: [HACKERS] BUG #7534: walreceiver takes long time to detect n/w breakdown

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Date: 2012-10-09 12:29:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
On Mon, Oct 8, 2012 at 10:42 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-10-09 12:35:03
Subject: Re: Placement of permissions checks for large object operations
Previous:From: Robert HaasDate: 2012-10-09 12:26:24
Subject: Re: PQntuples and PQgetvalue problem.

pgsql-bugs by date

Next:From: Amit KapilaDate: 2012-10-09 13:04:31
Subject: Re: [HACKERS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Previous:From: serovov+pgsqlDate: 2012-10-09 08:48:01
Subject: BUG #7589: Canceled "CREATE UNIQUE INDEX CONCURRENTLY" leavenot-fully-build index existing

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