Robert Haas wrote:
On Thu, Feb 11, 2010 at 2:15 AM, Tollef Fog Heen
<tollef.fog.h...@collabora.co.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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
