Re: TCP keepalive support for libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, 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:50:40
Message-ID: 3373.1277225440@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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?

By that argument, we need to be programming to bare metal on every disk
access. Does anyone want to argue that depending on vendor-specific
filesystem functionality is not a house of cards? (And unfortunately,
that's much too close to the truth ... but yet we're not going there.)

As for the original point: *of course* we are going to have to expose
the keepalive parameters. The default timeouts are specified by RFC,
and they're of the order of hours. That's not going to satisfy anyone
for this usage.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-06-22 17:00:22 Re: pg_upgrade issues
Previous Message Hiroshi Saito 2010-06-22 16:50:39 Re: pg_upgrade issues