On Tue, Jun 22, 2010 at 3:45 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jun 22, 2010 at 3:28 PM, Robert Haas <robertmh...@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
libpq-optional-keepalive-v2.diff
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
