From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Tollef Fog Heen <tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)uk>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TCP keepalive support for libpq |
Date: | 2010-06-22 13:27:28 |
Message-ID: | AANLkTim5oRwQ16LO457wzd4p0f9kdi9YHsySe1r1ZcGN@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 22, 2010 at 15:20, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Feb 15, 2010 at 8:58 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Tue, Feb 16, 2010 at 1:18 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> I'm all for this as a 9.1 submission, but let's not commit to trying to
>>>> debug it now. I would like a green buildfarm for awhile before we wrap
>>>> alpha4, and this sort of untested "it can't hurt" patch is exactly what
>>>> is likely to make things not green.
>>>
>>> Mmm. OK, fair enough.
>>
>> Okay. I added the patch to the first CF for v9.1.
>> Let's discuss about it later.
>
> There is talk of applying this patch, or something like it, for 9.0,
> so I guess now is the time for discussion. The overriding issue is
> that we need walreceiver to notice if the master goes away. Rereading
> this thread, the major argument against applying this patch is that it
> changes the default behavior: it ALWAYS enables keepalives, and then
> additionally provides libpq parameters to change some related
> parameters (number of seconds between sending keepalives, number of
> seconds after which to retransmit a keepalive, number of lost
> keepalives after which a connection is declared dead). Although the
> consensus seems to be that keepalives are a good idea much more often
> than not, I am wary of unconditionally turning on a behavior that has,
> in previous releases, been unconditionally turned off. I don't want
> to do this in 9.0, and I don't think I want to do it in 9.1, either.
>
> What I think would make sense is to add an option to control whether
> keepalives get turned on. If you say keepalives=1, you get on = 1;
> setsockopt(conn->sock, SOL_SOCKET, SO_KEEPALIVE,
> (char *) &on, sizeof(on); if you say keepalives=0, we do nothing
> special. If you say neither, you get the default behavior, which I'm
> inclined to make keepalives=1. That way, everyone gets the benefit of
> this patch (keepalives turned on) by default, but if for some reason
> someone is using libpq over the deep-space network or a connection for
> which they pay by the byte, they can easily shut it off. We can note
> the behavior change under "observe the following incompatibilities".
+1 on enabling it by default, but providing a switch to turn it off.
> I am inclined to punt the keepalives_interval, keepalives_idle, and
> keepalives_count parameters to 9.1. If these are needed for
> walreciever to work reliably, this whole approach is a dead-end,
> because those parameters are not portable. I will post a patch later
> today along these lines.
Do we know how unportable? If it still helps the majority, it might be
worth doing. But I agree, if it's not really needed for walreceiver,
then it should be punted to 9.1.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-06-22 16:16:49 | Re: TCP keepalive support for libpq |
Previous Message | Robert Haas | 2010-06-22 13:20:39 | Re: TCP keepalive support for libpq |