From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tollef Fog Heen <tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)uk> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TCP keepalive support for libpq |
Date: | 2010-02-09 13:45:01 |
Message-ID: | 9837222c1002090545o751b8d5aqebb7969c02292de8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 9, 2010 at 14:03, Tollef Fog Heen
<tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)uk> 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.
Seems reasonable to add this. Are there any scenarios where this can
cause trouble, that would be fixed by having the ability to select
non-standard behavior?
I don't recall ever changing away from the standard behavior in any of
my deployments, but that might be platform dependent?
If not, I think this is small and trivial enough not to have to push
back for 9.1 ;)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Jeroen Vermeulen | 2010-02-09 13:46:55 | Re: Avoiding bad prepared-statement plans. |
Previous Message | Tollef Fog Heen | 2010-02-09 13:03:28 | TCP keepalive support for libpq |