TCP keepalive support for libpq
in [PgSql]
|
From: Dimitri Fontaine on 11 Feb 2010 11:38 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > those people who create 2000 lightly used connections to the > database might feel differently. Yeah I still run against installation using the infamous PHP pconnect() function. You certainly don't want to add some load there, but that could urge them into arranging for being able to use pgbouncer in transaction pooling mode (and stop using pconnect(), damn it). Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Kris Jurka on 11 Feb 2010 12:23 On Thu, 11 Feb 2010, Andrew Chernow wrote: > > Although, I think Dave's comments have made me change my mind about this > patch. Looks like it serves a good purpose. That said, there is no > guarentee the driver will implement the new feature ... JDBC seems to > lack the ability to get the backing Socket object but java can set > socket options. Maybe a JDBC kong fu master knows how to do this. Use the tcpKeepAlive connection option as described here: http://jdbc.postgresql.org/documentation/84/connect.html#connection-parameters Java can only enable/disable keep alives, it can't set the desired timeout. http://java.sun.com/javase/6/docs/api/java/net/Socket.html#setKeepAlive%28boolean%29 Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tollef Fog Heen on 11 Feb 2010 02:15 ]] 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. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Kreen on 12 Feb 2010 10:50 On 2/11/10, Tollef Fog Heen <tollef.fog.heen(a)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.html Linux supports all 3, Windows 2, BSDs only keepidle. I would prefer 3) or 1) to 2). -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Euler Taveira de Oliveira on 12 Feb 2010 12:13
Marko Kreen escreveu: > 3) Support all 3 parameters (keepidle, keepintvl, keepcnt) > and ignore parameters not supported by OS. > +1. AFAIR, we already do that for the backend. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |