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

Re: TCP keepalive support for libpq

From: Andrew Chernow <ac(at)esilo(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tollef Fog Heen <tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: TCP keepalive support for libpq
Date: 2010-02-11 16:34:52
Message-ID: 4B7431AC.1010209@esilo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas wrote:
> On Thu, Feb 11, 2010 at 2:15 AM, Tollef Fog Heen
> <tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)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/

In response to

pgsql-hackers by date

Next:From: Oleg BartunovDate: 2010-02-11 16:37:56
Subject: Re: knngist patch support
Previous:From: Peter GeogheganDate: 2010-02-11 16:33:35
Subject: Re: TCP keepalive support for libpq

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