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

Re: TCP keepalive support for libpq

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Tollef Fog Heen <tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)uk>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TCP keepalive support for libpq
Date: 2010-06-22 16:16:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jun 22, 2010 at 9:27 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> I am inclined to punt the keepalives_interval, keepalives_idle, and
>> keepalives_count parameters to 9.1.  If these are needed for
>> walreciever to work reliably, this whole approach is a dead-end,
>> because those parameters are not portable.  I will post a patch later
>> today along these lines.
> Do we know how unportable? If it still helps the majority, it might be
> worth doing. But I agree, if it's not really needed for walreceiver,
> then it should be punted to 9.1.

This might not be such a good idea as I had thought.  It looks like
the default parameters on Linux (Fedora 12) are:


[ See also ]

That's clearly better than no keepalives, but I venture to say it's
not going to be anything close to the behavior people want for
walreceiver...  I think we're going to need to either vastly reduce
the keepalive time and interval, or abandon the strategy of using TCP
keepalives completely.

Which brings us to the question of portability.  A quick search around
the Internet suggests that this is supported on recent versions of
Linux, Free/OpenBSD, AIX, and HP/UX, and it appears to work on my Mac
also.  I'm not clear how long it's been implemented on each of these
platforms, though.  With respect to Windows, it looks like there are
registry settings for all of these parameters, but I'm unclear whether
they can be set on a per-connection basis and what's required to make
this happen.

Robert Haas
The Enterprise Postgres Company

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-06-22 16:31:51
Subject: Re: pg_upgrade issues
Previous:From: Magnus HaganderDate: 2010-06-22 13:27:28
Subject: Re: TCP keepalive support for libpq

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