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

From Robert Haas
Subject Re: TCP keepalive support for libpq
Date
Msg-id 603c8f071002110816rf74f73bhdefcab3da16eed60@mail.gmail.com
Whole thread Raw
In response to Re: TCP keepalive support for libpq  (Tollef Fog Heen <tollef.fog.heen@collabora.co.uk>)
Responses Re: TCP keepalive support for libpq  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: TCP keepalive support for libpq  (Andrew Chernow <ac@esilo.com>)
Re: TCP keepalive support for libpq  (Tollef Fog Heen <tollef.fog.heen@collabora.co.uk>)
List pgsql-hackers
On Thu, Feb 11, 2010 at 2:15 AM, Tollef Fog Heen
<tollef.fog.heen@collabora.co.uk> wrote:
> ]] daveg
>
> | I disagree. I have clients who have problems with leftover client connections
> | due to server host failures. They do not write apps in C. For a non-default
> | change to be effective we would need to have all the client drivers, eg JDBC,
> | psycopg, DBD-DBI, and the apps like psql make changes to turn it on. Adding
> | this option as a non-default will not really help.
>
> FWIW, this is my case.  My application uses psycopg, which provides no
> way to get access to the underlying socket.  Sure, I could hack my way
> around this, but from the application writer's point of view, I have a
> connection that I expect to stay around and be reliable.  Whether that
> connection is over a UNIX socket, a TCP socket or something else is
> something I would rather not have to worry about; it feels very much
> like an abstraction violation.

I've sometimes wondered why keepalives aren't the default for all TCP
connections.  They seem like they're usually a Good Thing (TM), but I
wonder if we can think of any situations where someone might not want
them?

...Robert


pgsql-hackers by date:

Previous
From: Tollef Fog Heen
Date:
Subject: Re: TCP keepalive support for libpq
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Output configuration status after ./configure run.