Re: TCP keepalive support for libpq

On 2/11/10, Tollef Fog Heen <tollef.fog.heen@collabora.co.uk> wrote:
>  | 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.

FYI, psycopg does support setting keepalive on fd:
 http://github.com/markokr/skytools-dev/blob/master/python/skytools/psycopgwrapper.py#L105


The main problem with generic keepalive support is the inconsistencies
between OS'es.  I see 3 ways to handle it:

1) Let user set it on libpq's fd, as now.
2) Give option to set keepalive=on/off, but no timeouts
3) Support all 3 parameters (keepidle, keepintvl, keepcnt)and ignore parameters not supported by OS.  Details here:
http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.htmlLinuxsupports all 3, Windows 2, BSDs only keepidle.
 

I would prefer 3) or 1) to 2).

-- 
marko