Re: Keepalives win32

2010/6/30 Pavel Golub <pavel(at)microolap(dot)com>:
> Hello, Bruce.
>
> You wrote:
>
> BM> Tom Lane wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> > On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 speaking of, if they're not the registry entries; and I
>>> >> definitely don't see the point of consulting such values if they aren't
>>> >> user-settable.  We might as well just consult the RFCs and be done.
>>>
>>> > FWIW, I think I prefer Magnus's approach, but I'm not 100% sure I can
>>> > defend that preference...
>>>
>>> Well, basically what I don't like about Magnus' proposal is that setting
>>> one of the two values changes the default that will be used for the
>>> other one.  (Or, if it does not change the default, the extra code is
>>> useless anyway.)  If we just always go through the WSAIoctl() path then
>>> we can clearly document "the default for this on Windows is so-and-so".
>>> How is the documentation going to explain the behavior of the proposed
>>> code?
>
> BM> Let's look at the usage probabilities.  99% of Win32 users will not use
> BM> any of these settings.
>
> Let me disagree with this statement. As DAC developer I'm faced with
> opposite reality. There are a lot of users demanding this
> functionality.

It's very intersting to hear from somebody who expects to actually use
this. But are you aware that we're only talking about *adjusting* the
keepalive values, not enabling them? Because we will, as the code
stands now, enable keepalive by defaults - just use the system default
values for timeout intervals. (Meaning this is how we do it on Unix as
of HEAD, irregardless of my patch)

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 default).

2) When not configured, use RFC defaults (overwrite system defaults).
When only one of the two parameters configured, use RFC default for
the other one (overwrite system default)

3) When not configured, use system defaults. When only one of the two
parameters configured, throw error.

I can see pros and cons with both. Given that I still think *most*
people will not configure the intervals at all, I think #1 is the one
that follows "principle of least surprise". Perhaps option *3* is the
one that does this for partial configuration?

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