Hello, Bruce. You wrote:
BM> Tom Lane wrote: >> Robert Haas <robertmh...@gmail.com> writes: >> > On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane <t...@sss.pgh.pa.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. BM> I would hate to come up with a solution that BM> changes the default behavior for that 99%. BM> Therefore, I think using hard-coded defaults only for cases where BM> someone sets one but not all settings is appropriate. The documentation BM> text would be: BM> On Windows, if a keepalive settings is set, then defaults will be BM> used for any unset values, specifically, keepalives_idle (200) and BM> keepalives_interval(4). Windows does not allow control of BM> keepalives_count. BM> Seems simple enough. BM> -- BM> Bruce Momjian <br...@momjian.us> http://momjian.us BM> EnterpriseDB http://enterprisedb.com BM> + None of us is going to be here forever. + -- With best wishes, Pavel mailto:pa...@gf.microolap.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
