Re: TCP keepalive support for libpq
От | Robert Haas |
---|---|
Тема | Re: TCP keepalive support for libpq |
Дата | |
Msg-id | 603c8f071002110816rf74f73bhdefcab3da16eed60@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TCP keepalive support for libpq (Tollef Fog Heen <tollef.fog.heen@collabora.co.uk>) |
Ответы |
Re: TCP keepalive support for libpq
Re: TCP keepalive support for libpq Re: TCP keepalive support for libpq |
Список | pgsql-hackers |
On Thu, Feb 11, 2010 at 2:15 AM, Tollef Fog Heen <tollef.fog.heen@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? ...Robert
В списке pgsql-hackers по дате отправления: