From: Magnus Hagander on
2010/2/10 daveg <daveg(a)sonic.net>:
> On Tue, Feb 09, 2010 at 09:34:10AM -0500, Andrew Chernow wrote:
>> Tollef Fog Heen wrote:
>> >(please Cc me on replies, I am not subscribed)
>> >
>> >Hi,
>> >
>> >libpq currently does not use TCP keepalives.  This is a problem in our
>> >case where we have some clients waiting for notifies and then the
>> >connection is dropped on the server side.  The client never gets the FIN
>> >and thinks the connection is up.  The attached patch unconditionally
>> >adds keepalives.  I chose unconditionally as this is what the server
>> >does.  We didn't need the ability to tune the timeouts, but that could
>> >be added with reasonable ease.
>>
>> ISTM that the default behavior should be keep alives disabled, as it is
>> now, and those wanting it can just set it in their apps:
>>
>> setsockopt(PQsocket(conn), SOL_SOCKET, SO_KEEPALIVE, ...)
>
> 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.

Yes, that's definitely the use-case. PQsocket() will work fine for C apps only.

But it should work fine as an option, no? As long as you can specify
it on the connection string - I don't think there are any interfaces
that won't take a connection string?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.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

From: Fujii Masao on
On Fri, Feb 12, 2010 at 1:33 AM, Peter Geoghegan
<peter.geoghegan86(a)gmail.com> wrote:
> Why hasn't libpq had keepalives for years?

I guess that it's because keepalive doesn't work as expected
in some cases. For example, if the network outage happens
before a client sends some packets, keepalive doesn't work,
then it would have to wait for a long time until it detects
the outage. This is the specification of linux kernel. So
a client should not have excessive expectations of keepalive,
and should have another timeout like QueryTimeout of JDBC.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
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: Andrew Chernow on

>>> ISTM that the default behavior should be keep alives disabled, as it is
>>> now, and those wanting it can just set it in their apps:
>>>
>>> setsockopt(PQsocket(conn), SOL_SOCKET, SO_KEEPALIVE, ...)
>> 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.
>
> Yes, that's definitely the use-case. PQsocket() will work fine for C apps only.
>
> But it should work fine as an option, no? As long as you can specify
> it on the connection string - I don't think there are any interfaces
> that won't take a connection string?
>

Perl and python appear to have the same abilities as C. I don't use either of
these drivers but I *think* the below would work:

DBD:DBI
setsockopt($dbh->pg_socket(), ...);

psycopg
conn.cursor().socket().setsockopt(...);

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.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.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

From: Robert Haas on
On Thu, Feb 11, 2010 at 2:15 AM, Tollef Fog Heen
<tollef.fog.heen(a)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

--
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: "Kevin Grittner" on
Robert Haas <robertmhaas(a)gmail.com> wrote:

> 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?

I think it's insane not to use them at all, but there are valid use
cases for different timings. Personally, I'd be happy to see a
default of sending them if a connection is idle for two minutes, but
those people who create 2000 lightly used connections to the
database might feel differently.

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers