Re: SO_KEEPALIVE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SO_KEEPALIVE
Date
Msg-id 23013.1116294660@sss.pgh.pa.us
Whole thread Raw
In response to Re: SO_KEEPALIVE  (Hannu Krosing <hannu@tm.ee>)
Responses Re: SO_KEEPALIVE  (Dennis Bjorklund <db@zigo.dhs.org>)
Re: SO_KEEPALIVE  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-hackers
Hannu Krosing <hannu@tm.ee> writes:
> On E, 2005-05-16 at 19:22 +0200, Dennis Bjorklund wrote:
>> Wouldn't the client also want to know that the server is not there
>> anymore? I talked to Gaetano Mendola (I think, but you never know on irc
>> :-) and he had some clients that had been hanging around for 3 days after
>> the server had been down and later up again (stuck in recv).

> "stuck in recv" is symptom of a reconnect bug when libpq first tries to
> test for a SSL connection but the connect has already gone away.
> (search for "[HACKERS] oldish libpq bug still in RC2" in lists)
> Tom fixed it in no time once I showed him where to look and provided a
> test case. It should be fixed in 8.0.

> I don't know if the fix was backported to older libpq versions as well.

It was not ... but I'm not convinced that that bug explains Gaetano's
problem.  If you'll recall, that bug caused libpq to get into a tight
loop chewing CPU.  It should be pretty easy to tell the difference
between that and sitting idle because there is nothing happening.

On the other hand, it seems to me a client-side SO_KEEPALIVE would only
be interesting for completely passive clients (perhaps one that sits
waiting for NOTIFY messages?)  A normal client will try to issue some
kind of database command once in awhile, and as soon as that happens,
there is a reasonably short timeout before connection failure is reported.
        regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: SQL99 hierarchical queries stalled
Next
From: Alvaro Herrera
Date:
Subject: Re: Best way to scan on-disk bitmaps