Re: TCP keepalive support for libpq - Mailing list pgsql-hackers

From Robert Haas
Subject Re: TCP keepalive support for libpq
Date
Msg-id AANLkTinEFooRK1Cn6k7d3vAe5YKbOK72GQPeW2rWMWWc@mail.gmail.com
Whole thread Raw
In response to Re: TCP keepalive support for libpq  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: TCP keepalive support for libpq  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Tue, Jun 22, 2010 at 3:45 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jun 22, 2010 at 3:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Either I'm doing something wrong,
>
> I think it's this one.  Stand by.

OK, here's a new version with several fewer bugs.  This does appear to
work on both Linux and MacOS now, which are the platforms I have
handy, and it does in fact solve the problem with walreceiver given
the following contents for recovery.conf:

primary_conninfo='host=192.168.84.136 keepalives_count=5
keepalives_interval=10 keepalives_idle=30'
standby_mode='on'

In theory, we could apply this as-is and call it good: if you want
master failures to be detected faster than they will be with the
default keepalive settings, do the above (assuming your platform
supports it).  Or we could try to be more clever, though the exact
shape of that cleverness is not obvious to me at this point.

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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Parallel pg_restore versus old dump files
Next
From: Alexander Korotkov
Date:
Subject: Re: Using multidimensional indexes in ordinal queries