Horton

Thread

  1. SO_KEEPALIVE

    Dennis Björklund <db@zigo.dhs.org> — 2005-05-16T14:45:06Z

    How come we don't set SO_KEEPALIVE in libpq? 

Is there any reason why we wouldn't want it on?

-- 
/Dennis Björklund

  2. Re: SO_KEEPALIVE

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-05-16T16:40:36Z

    Dennis Bjorklund <db@zigo.dhs.org> writes:
> How come we don't set SO_KEEPALIVE in libpq? 
> Is there any reason why we wouldn't want it on?

Is there any reason we *would* want it on?  The server-side keepalive
should be sufficient to get whatever useful impact it might have.

			regards, tom lane

  3. Re: SO_KEEPALIVE

    Dennis Björklund <db@zigo.dhs.org> — 2005-05-16T17:22:47Z

    On Mon, 16 May 2005, Tom Lane wrote:

> > How come we don't set SO_KEEPALIVE in libpq? 
> > Is there any reason why we wouldn't want it on?
> 
> Is there any reason we *would* want it on?  The server-side keepalive
> should be sufficient to get whatever useful impact it might have.

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).

Server-side keepalive is enough for the server to clean up when clients
disapears, but this do nothing to help clients detect that the server is
gone. So I don't see what server side keepalive has to do with it.

-- 
/Dennis Björklund

  4. Re: SO_KEEPALIVE

    Hannu Krosing <hannu@tm.ee> — 2005-05-16T22:08:08Z

    On E, 2005-05-16 at 19:22 +0200, Dennis Bjorklund wrote:
> On Mon, 16 May 2005, Tom Lane wrote:
> 
> > > How come we don't set SO_KEEPALIVE in libpq? 
> > > Is there any reason why we wouldn't want it on?
> > 
> > Is there any reason we *would* want it on?  The server-side keepalive
> > should be sufficient to get whatever useful impact it might have.
> 
> 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.

> Server-side keepalive is enough for the server to clean up when clients
> disapears, but this do nothing to help clients detect that the server is
> gone. So I don't see what server side keepalive has to do with it.

-- 
Hannu Krosing <hannu@tm.ee>

  5. Re: SO_KEEPALIVE

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-05-17T01:51:00Z

    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

  6. Re: SO_KEEPALIVE

    Dennis Björklund <db@zigo.dhs.org> — 2005-05-17T04:40:38Z

    On Mon, 16 May 2005, Tom Lane wrote:

> 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

At least some of the clients was psql.

-- 
/Dennis Björklund

  7. Re: SO_KEEPALIVE

    Oliver Jowett <oliver@opencloud.com> — 2005-05-18T13:38:25Z

    Tom Lane wrote:

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

If you're unlucky, the server could go down while you're blocked waiting
for a query response..

-O

  8. Re: SO_KEEPALIVE

    Gaetano Mendola <mendola@bigfoot.com> — 2005-05-18T13:49:00Z

    Oliver Jowett wrote:

> If you're unlucky, the server could go down while you're blocked waiting
> for a query response..
> 

That is exactly what happens to us, and you have to be not so unlucky for
that happen if the engine have ~100 query at time.

Regards
Gaetano Mendola

  9. Re: SO_KEEPALIVE

    Gaetano Mendola <mendola@bigfoot.com> — 2005-05-18T14:15:30Z

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Oliver Jowett wrote:



>>>> If you're unlucky, the server could go down while you're blocked waiting
>>>> for a query response..
>>>>



That is exactly what happens to us, and you have to be not so unlucky for
that happen if the engine have ~100 query at time.

Regards
Gaetano Mendola




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCi04C7UpzwH2SGd4RArvMAKDUJEefpsH2CX9E6wjg2j5DcV3JSwCgr/XB
BlTc3y4vE9GjyUl6eypcN00=
=h/Gg
-----END PGP SIGNATURE-----