From: Magnus Hagander on
On Wed, Jun 30, 2010 at 17:46, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes:
>> I also think we may want to suggest that for most environments,
>> people may want to change these settings to something more
>> aggressive, like a 30 to 120 second initial delay, with a 10 or 20
>> second retry interval.  The RFC defaults seem approximately right
>> for a TCP connection to a colony on the surface of the moon, where
>> besides the round trip latency of 2.5 seconds they might have to pay
>> by the byte.
>
> Well, the RFCs were definitely written at a time when bandwidth was a
> lot more expensive than it is today.
>
>> In other words, it is *so* conservative that I have
>> trouble seeing it ever causing a problem compared to not having
>> keepalive enabled, but it will eventually clean things up.
>
> Yes.  This is a large part of the reason why I think it's okay for us to
> turn libpq keepalive on by default in 9.0 --- the default parameters for
> it are so conservative as to be unlikely to cause trouble.  If Windows
> isn't using RFC-equivalent default parameters, that seems like a good
> reason to disregard the system settings and force use of the RFC values
> as defaults.


Here's an updated version of the patch, which includes server side
functionality. I took out the code that tried to"be smart". It'll now
set them to 2 hours/1 second by default. I looked quickly at the RFC
and didn't find the exact values there, so those values are the
documented out-of-the-box defaults on Windows. I can easily change
them to RFC values if someone can find them for me :)

It's also merged with roberts macos patch, since they were conflicting.

Doc changes not included, but I'll get those in before commit.

Comments?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From: "Kevin Grittner" on
Magnus Hagander <magnus(a)hagander.net> wrote:

> It'll now set them to 2 hours/1 second by default. I looked
> quickly at the RFC and didn't find the exact values there, so those
> values are the documented out-of-the-box defaults on Windows. I
> can easily change them to RFC values if someone can find them for
> me :)

The RFC specifies 2 hours/75 seconds/9 tries. Even though we can't
reasonably adjust the number of tries up from 5 in Windows, I'd be
inclined to keep the 75 interval, rather than doubling it.

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on


Robert Haas wrote:
> (BTW, there are two buildfarm machines - wigeon and orangutan - that
> are consistently failing with rather bizarre error messages. Are
> these real failures or are those machines just messed up?)
>
>

Dave and Scott,

please investigate these errors in your buildfarm members.

cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Magnus Hagander on
On Wed, Jul 7, 2010 at 15:32, Robert Haas <robertmhaas(a)gmail.com> wrote:
> On Wed, Jul 7, 2010 at 9:20 AM, Magnus Hagander <magnus(a)hagander.net> wrote:
>> On Wed, Jun 30, 2010 at 17:46, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>>> "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes:
>>>> I also think we may want to suggest that for most environments,
>>>> people may want to change these settings to something more
>>>> aggressive, like a 30 to 120 second initial delay, with a 10 or 20
>>>> second retry interval. �The RFC defaults seem approximately right
>>>> for a TCP connection to a colony on the surface of the moon, where
>>>> besides the round trip latency of 2.5 seconds they might have to pay
>>>> by the byte.
>>>
>>> Well, the RFCs were definitely written at a time when bandwidth was a
>>> lot more expensive than it is today.
>>>
>>>> In other words, it is *so* conservative that I have
>>>> trouble seeing it ever causing a problem compared to not having
>>>> keepalive enabled, but it will eventually clean things up.
>>>
>>> Yes. �This is a large part of the reason why I think it's okay for us to
>>> turn libpq keepalive on by default in 9.0 --- the default parameters for
>>> it are so conservative as to be unlikely to cause trouble. �If Windows
>>> isn't using RFC-equivalent default parameters, that seems like a good
>>> reason to disregard the system settings and force use of the RFC values
>>> as defaults.
>>
>> Here's an updated version of the patch, which includes server side
>> functionality. I took out the code that tried to"be smart". It'll now
>> set them to 2 hours/1 second by default. I looked quickly at the RFC
>> and didn't find the exact values there, so those values are the
>> documented out-of-the-box defaults on Windows. I can easily change
>> them to RFC values if someone can find them for me :)
>>
>> It's also merged with roberts macos patch, since they were conflicting.
>>
>> Doc changes not included, but I'll get those in before commit.
>>
>> Comments?
>
> Looks generally OK, though my knowledge of Windows is pretty limited.
> We'd better get this committed PDQ if it's going into beta3, else
> there won't be a full buildfarm cycle before we wrap.

Committed.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers