Re: TCP keepalive support for libpq

On 2/11/10, Tollef Fog Heen <tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)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.html
Linux supports all 3, Windows 2, BSDs only keepidle.

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

--
marko