On Wed, Jul 7, 2010 at 15:32, Robert Haas wrote:
> On Wed, Jul 7, 2010 at 9:20 AM, Magnus Hagander wrote:
>> On Wed, Jun 30, 2010 at 17:46, Tom Lane wrote:
>>> "Kevin Grittner" writes:
I also think we may want to suggest that for most environments,
people may want to change these sett
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.
Magnus Hagander 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 :)
On Wed, Jul 7, 2010 at 9:20 AM, Magnus Hagander wrote:
> On Wed, Jun 30, 2010 at 17:46, Tom Lane wrote:
>> "Kevin Grittner" 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
On Wed, Jun 30, 2010 at 17:46, Tom Lane wrote:
> "Kevin Grittner" 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
Hello, Tom.
You wrote:
TL> Bruce Momjian writes:
>> Tom Lane wrote:
>>> What's your idea of "affecting the fewest people"? There is no previous
>>> history to be backward-compatible with, because we never supported
>>> keepalive on Windows before.
>> Well, starting in 9.0, keepalives in libpq
"Kevin Grittner" 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 T
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> What's your idea of "affecting the fewest people"? There is no previous
> >> history to be backward-compatible with, because we never supported
> >> keepalive on Windows before.
>
> > Well, starting in 9.0, keepalives in libpq will
Magnus Hagander wrote:
> Windows default for idle is 2 hours, for interval 1 second.
And it defaults to five retries. With these settings, you could
have a TCP connection break with as little as a five second network
outage, if it happened to come after two hours of silence on the
connection;
Bruce Momjian writes:
> Tom Lane wrote:
>> What's your idea of "affecting the fewest people"? There is no previous
>> history to be backward-compatible with, because we never supported
>> keepalive on Windows before.
> Well, starting in 9.0, keepalives in libpq will default to 'on':
Yes, which
Tom Lane wrote:
> Bruce Momjian writes:
> > I still like #1 because it affects the fewest people, and that option
> > uses the RFC defaults only for unset values when others are set.
>
> What's your idea of "affecting the fewest people"? There is no previous
> history to be backward-compatible w
Bruce Momjian writes:
> I still like #1 because it affects the fewest people, and that option
> uses the RFC defaults only for unset values when others are set.
What's your idea of "affecting the fewest people"? There is no previous
history to be backward-compatible with, because we never suppor
Magnus Hagander writes:
>> But you previously stated that this code was ignoring the registry
>> values. So doesn't "system defaults" boil down to whatever Windows'
>> wired-in defaults are?
> The order is Windows wired-in-defaults -> registry values -> what app chooses.
> And yes, we *are* ign
Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Jun 30, 2010 at 16:27, Tom Lane wrote:
> >> It's hard to argue about this when most of us have no idea what these
> >> "system defaults" are, or whether they really are any different from the
> >> RFC values in the first place, or whether ordi
On Wed, Jun 30, 2010 at 16:48, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Jun 30, 2010 at 16:27, Tom Lane wrote:
>>> It's hard to argue about this when most of us have no idea what these
>>> "system defaults" are, or whether they really are any different from the
>>> RFC values in the
Magnus Hagander writes:
> On Wed, Jun 30, 2010 at 16:27, Tom Lane wrote:
>> It's hard to argue about this when most of us have no idea what these
>> "system defaults" are, or whether they really are any different from the
>> RFC values in the first place, or whether ordinary users know how to
>>
On Wed, Jun 30, 2010 at 16:27, Tom Lane wrote:
> Magnus Hagander writes:
>> Do you have an opinion on the two choices for handling keepalives_idle
>> and keepalives_interval? They basically are:
>
>> 1) When not configured, use system defaults. When only one of the two
>> parameters configured, u
Magnus Hagander writes:
> Do you have an opinion on the two choices for handling keepalives_idle
> and keepalives_interval? They basically are:
> 1) When not configured, use system defaults. When only one of the two
> parameters configured, use RFC default for the other one (overwrite
> system de
Hello, Magnus.
You wrote:
MH> 2010/6/30 Pavel Golub :
>> Hello, Bruce.
>>
>> You wrote:
>>
>> BM> Tom Lane wrote:
Robert Haas writes:
> On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane wrote:
>> What I was trying to say is I think we could dispense with the
>> setsockopt() code pat
2010/6/30 Pavel Golub :
> Hello, Bruce.
>
> You wrote:
>
> BM> Tom Lane wrote:
>>> Robert Haas writes:
>>> > On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane wrote:
>>> >> What I was trying to say is I think we could dispense with the
>>> >> setsockopt() code path, and just always use the WSAIoctl() pat
Hello, Bruce.
You wrote:
BM> Tom Lane wrote:
>> Robert Haas writes:
>> > On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane wrote:
>> >> What I was trying to say is I think we could dispense with the
>> >> setsockopt() code path, and just always use the WSAIoctl() path anytime
>> >> keepalives are turne
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane wrote:
> >> What I was trying to say is I think we could dispense with the
> >> setsockopt() code path, and just always use the WSAIoctl() path anytime
> >> keepalives are turned on. ?I don't know what "system def
Robert Haas writes:
> On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane wrote:
>> What I was trying to say is I think we could dispense with the
>> setsockopt() code path, and just always use the WSAIoctl() path anytime
>> keepalives are turned on. I don't know what "system default values"
>> you're spe
On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Jun 28, 2010 at 22:39, Tom Lane wrote:
>>> I had in mind just legislating that the defaults are the RFC values,
>>> none of this "try to use the registry values in one case" business.
>
>> Um, if you look at th
Magnus Hagander writes:
> On Mon, Jun 28, 2010 at 22:39, Tom Lane wrote:
>> I had in mind just legislating that the defaults are the RFC values,
>> none of this "try to use the registry values in one case" business.
> Um, if you look at that patch, it doesn't try to use the registry. It
> falls
On Mon, Jun 28, 2010 at 22:39, Tom Lane wrote:
> Magnus Hagander writes:
>> Here's what I'm thinking, for the libpq side. Similar change on the
>> server side. Seems ok?
>
> I had in mind just legislating that the defaults are the RFC values,
> none of this "try to use the registry values in one
Magnus Hagander writes:
> Here's what I'm thinking, for the libpq side. Similar change on the
> server side. Seems ok?
I had in mind just legislating that the defaults are the RFC values,
none of this "try to use the registry values in one case" business.
I don't believe that you can make the ser
On Mon, Jun 28, 2010 at 21:10, Magnus Hagander wrote:
> On Mon, Jun 28, 2010 at 21:03, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Jun 28, 2010 at 20:45, Tom Lane wrote:
I vote for #2. It's the least inconsistent --- we don't pay attention
to the registry for much of anyth
The way I see it, we have two options:
1) Read the default value from the registry. That's some fairly ugly code, imho.
It seems faily simple to yank these values out, no? Even easier if you
use the all-in-wonder shell function SHGetValue().
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Ser
It seems faily simple to yank these values out, no? Even easier if you use
the all-in-wonder shell function SHGetValue().
We don't want to use that function, because it brings in a bunch of
extra dependencies. This makes libpq.dll more heavyweight and more
importantly, decreases the number o
On Mon, Jun 28, 2010 at 21:03, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Jun 28, 2010 at 20:45, Tom Lane wrote:
>>> I vote for #2. It's the least inconsistent --- we don't pay attention
>>> to the registry for much of anything else, do we?
>
>> Directly, no? Indirectly, we do. For ev
On Mon, Jun 28, 2010 at 21:03, Andrew Chernow wrote:
>
>>
>> The way I see it, we have two options:
>> 1) Read the default value from the registry. That's some fairly ugly code,
>> imho.
>
> It seems faily simple to yank these values out, no? Even easier if you use
> the all-in-wonder shell funct
Magnus Hagander writes:
> On Mon, Jun 28, 2010 at 20:45, Tom Lane wrote:
>> I vote for #2. It's the least inconsistent --- we don't pay attention
>> to the registry for much of anything else, do we?
> Directly, no? Indirectly, we do. For every other TCP parameter
> (because the registry control
On Mon, Jun 28, 2010 at 20:45, Tom Lane wrote:
> Magnus Hagander writes:
>> [ can't read system's keepalive values in windows ]
>
>> The way I see it, we have two options:
>> 1) Read the default value from the registry. That's some fairly ugly code,
>> imho.
>> 2) Ignore the registry value and u
Magnus Hagander writes:
> [ can't read system's keepalive values in windows ]
> The way I see it, we have two options:
> 1) Read the default value from the registry. That's some fairly ugly code,
> imho.
> 2) Ignore the registry value and use the default value of 2 hours/1
> second. That will ov
Hi!
I'm looking at adding win32 support for keepalives in libpq (well,
also backend, but libpq for now), per the request from Robert Haas.
I've come up with one issue though - in Windows, you can only set the
"idle" and "interval" parameter together in a single syscall (in Unix,
you have one for e
36 matches
Mail list logo
