Prev: Propose Beta3 for July
Next: [HACKERS] keepalives on MacOS X
From: Tom Lane on 28 Jun 2010 14:45
Magnus Hagander <magnus(a)hagander.net> 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 override any changes the user made in the registry,
> which seems pretty ugly.
> 3) Require that these two parameters are always specified together (on
> windows). Which is annoying.

I vote for #2. It's the least inconsistent --- we don't pay attention
to the registry for much of anything else, do we?

In practice I think people who were setting either would set both, so
it's not worth a huge amount of effort to have an unsurprising behavior
when only one is set.

regards, tom lane

--
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 28 Jun 2010 14:48
On Mon, Jun 28, 2010 at 20:45, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus(a)hagander.net> 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 override any changes the user made in the registry,
>> which seems pretty ugly.
>> 3) Require that these two parameters are always specified together (on
>> windows). Which is annoying.
>
> 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 controls what we'll get as the default when we
"just use things")

> In practice I think people who were setting either would set both, so
> it's not worth a huge amount of effort to have an unsurprising behavior
> when only one is set.

There's unsurprising, and downright hostile (the way we get by default
is if you don't set keepalive_time, it'll spew keepalive packages
continuously, which is certainly not good). In tha tcase, it's
probably better to throw an error (which would be trivial to do, of
course)

--
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

From: Tom Lane on 28 Jun 2010 15:03
Magnus Hagander <magnus(a)hagander.net> writes:
> On Mon, Jun 28, 2010 at 20:45, Tom Lane <tgl(a)sss.pgh.pa.us> 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 controls what we'll get as the default when we
> "just use things")

Not if we make the code use the RFC values as the defaults. I'm
envisioning the GUC assign hooks doing something like

#ifdef WIN32
if (newval == 0)
newval = RFC-specified-default;
#endif

so that the main GUC logic can still think that zero means "use the
default". We're just redefining where the default comes from.

This would be a change from previous behavior, but so what?
Implementing any functionality at all here is a change from previous
behavior on Windows. I don't have the slightest problem with saying
"as of 9.0, set these values via postgresql.conf, not the registry".

regards, tom lane

--
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 28 Jun 2010 15:07
On Mon, Jun 28, 2010 at 21:03, Andrew Chernow <ac(a)esilo.com> 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 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 of parallell connections we can deal
with on the server side (on win32 at least, not sure about win64).

> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
> Values: KeepAliveTime, KeepAliveInterval
> Type: DWORD
>
> The only annoying thing is that the values may not exist. �Well, it is also

Right, we'd need an fallback in case they don't exist as well.


> rather annoying there is no way to set the counter.

Yeah, but that's at least well documented how it behaves. In fact,
there used to be a way to set that (via registry key), but they
removed it in Vista.


--
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

From: Magnus Hagander on 28 Jun 2010 15:10
On Mon, Jun 28, 2010 at 21:03, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus(a)hagander.net> writes:
>> On Mon, Jun 28, 2010 at 20:45, Tom Lane <tgl(a)sss.pgh.pa.us> 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 controls what we'll get as the default when we
>> "just use things")
>
> Not if we make the code use the RFC values as the defaults. �I'm
> envisioning the GUC assign hooks doing something like
>
> #ifdef WIN32
> � � � �if (newval == 0)
> � � � � � � � �newval = RFC-specified-default;
> #endif

Right. (I've only looked at the libpq side so far)

Also, we could avoid caling it *at all* if neither one of those
parameters is set. That'll take a bit more code (using the
unix-codepath of setsockopt() to enable keepalives at all), but it
shouldn't amount to many lines..


> so that the main GUC logic can still think that zero means "use the
> default". �We're just redefining where the default comes from.

Yeah.


> This would be a change from previous behavior, but so what?
> Implementing any functionality at all here is a change from previous
> behavior on Windows. �I don't have the slightest problem with saying
> "as of 9.0, set these values via postgresql.conf, not the registry".

Works for me.

--
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

 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Propose Beta3 for July
Next: [HACKERS] keepalives on MacOS X