Re: Keepalives win32
От | Bruce Momjian |
---|---|
Тема | Re: Keepalives win32 |
Дата | |
Msg-id | 201006300009.o5U09xj01803@momjian.us обсуждение исходный текст |
Ответ на | Re: Keepalives win32 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Keepalives win32
|
Список | pgsql-hackers |
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane <tgl@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? Let's look at the usage probabilities. 99% of Win32 users will not use any of these settings. I would hate to come up with a solution that changes the default behavior for that 99%. Therefore, I think using hard-coded defaults only for cases where someone sets one but not all settings is appropriate. The documentation text would be: On Windows, if a keepalive settings is set, then defaults will beused for any unset values, specifically, keepalives_idle(200) andkeepalives_interval(4). Windows does not allow control ofkeepalives_count. Seems simple enough. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
В списке pgsql-hackers по дате отправления: