[HACKERS] SO_KEEPALIVE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I understood that noone will add that option to pglib, is it correct ? Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCkOh27UpzwH2SGd4RAuh1AJ92B4qZiYZmd40+v4QwmCJyM7z0ggCbBSon g75HfsDdfdSRuIVXEqFe6+g= =I+X/ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SO_KEEPALIVE
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] SO_KEEPALIVE
-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- ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SO_KEEPALIVE
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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] SO_KEEPALIVE
How come we don't set SO_KEEPALIVE in libpq? Is there any reason why we wouldn't want it on? -- /Dennis Björklund ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] SO_KEEPALIVE
Dennis Bjorklund [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SO_KEEPALIVE
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] SO_KEEPALIVE
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SO_KEEPALIVE
Hannu Krosing [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] SO_KEEPALIVE
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
