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
