Re: Keepalives win32

Hello, Magnus.

You wrote:

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

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

MH> Do you have an opinion on the two choices for handling keepalives_idle
MH> and keepalives_interval? They basically are:

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

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

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

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

Frankly speaking I cannot decide what is the best approach. :) It's up
to you guys.

--
With best wishes,
Pavel mailto:pavel(at)gf(dot)microolap(dot)com