Re: Keepalives win32

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Keepalives win32
Date: 2010-06-28 18:48:36
Message-ID: AANLkTin29ogn1vtrFWRuagz_iFa639oCYgQFJvk4-IYO@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 28, 2010 at 20:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-06-28 18:52:09 Re: get_whatever_oid, part 1: object types with unqualifed names
Previous Message Josh Berkus 2010-06-28 18:47:36 Re: hstore ==> and deprecate =>