Re: TCP keepalive support for libpq

Robert Haas wrote:
> 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?
> 

The only case I can think of are systems that send application layer 
keepalive-like packets; I've worked on systems like this.  The goal 
wasn't to reinvent keepalives but to check-in every minute or two to 
meet a different set of requirements, thus TCP keepalives weren't 
needed.  However, I don't think they would of caused any harm.

The more I think about this the more I think it's a pretty non-invasive 
change to enable keepalives in libpq.  I don't think this has any 
negative impact on clients written while the default was disabled.

This is really a driver setting.  There is no way to ensure libpq, DBI, 
psycopg, JDBC, etc... all enable or disable keepalives by default.  I 
only bring this up because it appears there are complaints from 
non-libpq clients.  This patch wouldn't fix those cases.

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/