Re: TCP keepalive support for libpq

Florian Pflug <fgp@phlo.org>

From: Florian Pflug <fgp@phlo.org>

To: Robert Haas <robertmhaas@gmail.com>

Cc: Magnus Hagander <magnus@hagander.net>, Fujii Masao <masao.fujii@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Euler Taveira de Oliveira <euler@timbira.com>, Marko Kreen <markokr@gmail.com>, Tollef Fog Heen <tollef.fog.heen@collabora.co.uk>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2010-06-22T17:30:55Z

Lists: pgsql-hackers

On Jun 22, 2010, at 18:43 , Robert Haas wrote:
> What does bother me is the fact that we are engineering a critical
> aspect of our system reliability around vendor-specific implementation
> details of the TCP stack, and that if any version of any operating
> system that we support (or ever wish to support in the future) fails
> to have a reliable implementation of this feature AND configurable
> knobs that we can tune to suit our needs, then we're screwed.  Does
> anyone want to argue that this is NOT a house of cards?

We already depend on TCP keepalives to prevent backends orphaned by client crashes or network outages from lingering around forever. If such a lingering backend is inside a transaction, I'll cause table bloat, prevent clog truncations, and keep tables locked forever.

I'd therefore argue that lingering backends are as least as severe a problem as hung S/R connections are. Since we've trusted keepalives to prevent the former for 10 years now, I think we can risk trusting keepalives to prevent the latter too.

best regards,
Florian Pflug