Keepalives win32
in [PgSql]
|
From: Tom Lane on 28 Jun 2010 20:24 Magnus Hagander <magnus(a)hagander.net> writes: > On Mon, Jun 28, 2010 at 22:39, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> I had in mind just legislating that the defaults are the RFC values, >> none of this "try to use the registry values in one case" business. > Um, if you look at that patch, it doesn't try to use the registry. It > falls back directly to the system default, ignoring the registry. The > only special case is where the user doesn't specify any of the > parameters. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 Jun 2010 09:35 On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Magnus Hagander <magnus(a)hagander.net> writes: >> On Mon, Jun 28, 2010 at 22:39, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> I had in mind just legislating that the defaults are the RFC values, >>> none of this "try to use the registry values in one case" business. > >> Um, if you look at that patch, it doesn't try to use the registry. It >> falls back directly to the system default, ignoring the registry. The >> only special case is where the user doesn't specify any of the >> parameters. > > 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... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 29 Jun 2010 10:59 Robert Haas <robertmhaas(a)gmail.com> writes: > On Mon, Jun 28, 2010 at 8:24 PM, Tom Lane <tgl(a)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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 30 Jun 2010 11:09 Bruce Momjian <bruce(a)momjian.us> writes: > I still like #1 because it affects the fewest people, and that option > uses the RFC defaults only for unset values when others are set. What's your idea of "affecting the fewest people"? There is no previous history to be backward-compatible with, because we never supported keepalive on Windows before. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 30 Jun 2010 11:46
"Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > I also think we may want to suggest that for most environments, > people may want to change these settings to something more > aggressive, like a 30 to 120 second initial delay, with a 10 or 20 > second retry interval. The RFC defaults seem approximately right > for a TCP connection to a colony on the surface of the moon, where > besides the round trip latency of 2.5 seconds they might have to pay > by the byte. Well, the RFCs were definitely written at a time when bandwidth was a lot more expensive than it is today. > In other words, it is *so* conservative that I have > trouble seeing it ever causing a problem compared to not having > keepalive enabled, but it will eventually clean things up. Yes. This is a large part of the reason why I think it's okay for us to turn libpq keepalive on by default in 9.0 --- the default parameters for it are so conservative as to be unlikely to cause trouble. If Windows isn't using RFC-equivalent default parameters, that seems like a good reason to disregard the system settings and force use of the RFC values as defaults. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |