Win32 timezone matching
in [PgSql]
|
From: Tom Lane on 6 Apr 2010 17:44 Magnus Hagander <magnus(a)hagander.net> writes: > When diagnosing a problem for a guy in the german channel (with Stefan > as mediator :P), we've found a case where the timezone information in > the registry seem to be empty for some timezones. The current timezone > matching code will abort scanning when it comes across one of these, > thus claiming it can't match the timezone, and reverting to GMT. > We've seen some reports prevously that looked like this, but never > really managed to get it diagnosed. Having checked the registry on > this machine, it appears to simply be that "Std" and "Dlt" are missing > from some entries. > The attach patch changes our scan to skip to the next timezone when > this happens, instead of aborting. The only downtime I can see from > this is that in case there are a *lot* of broken timezones (like "all > of them"), well log a lot of warnings. But it will only happen on > server startup, so I think it's ok. I'm not clear on this. Would this patch fix a real seen-in-the-field condition, or is it speculative? In particular, if the loop had kept going in the complainant's machine, would it have found another entry that worked better? 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: Magnus Hagander on 6 Apr 2010 17:52 On Tue, Apr 6, 2010 at 23:44, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Magnus Hagander <magnus(a)hagander.net> writes: >> When diagnosing a problem for a guy in the german channel (with Stefan >> as mediator :P), we've found a case where the timezone information in >> the registry seem to be empty for some timezones. The current timezone >> matching code will abort scanning when it comes across one of these, >> thus claiming it can't match the timezone, and reverting to GMT. > >> We've seen some reports prevously that looked like this, but never >> really managed to get it diagnosed. Having checked the registry on >> this machine, it appears to simply be that "Std" and "Dlt" are missing >> from some entries. > >> The attach patch changes our scan to skip to the next timezone when >> this happens, instead of aborting. The only downtime I can see from >> this is that in case there are a *lot* of broken timezones (like "all >> of them"), well log a lot of warnings. But it will only happen on >> server startup, so I think it's ok. > > I'm not clear on this. Would this patch fix a real seen-in-the-field > condition, or is it speculative? In particular, if the loop had kept > going in the complainant's machine, would it have found another entry > that worked better? Real, seen-in-the-field. It would proceed and eventually find the guys Berlin timezone (Central European, which comes after Central Brazilian which is the one that was missing the entries). It does, however, turn out that the issue was fixed when he re-applied the latest timezone update hotfix from microsoft, which appears to rewrite that entire subkey. Not sure how well we can trust that though - it's not like we're working off a documented key... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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 6 Apr 2010 17:59 Magnus Hagander <magnus(a)hagander.net> writes: > On Tue, Apr 6, 2010 at 23:44, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> I'm not clear on this. �Would this patch fix a real seen-in-the-field >> condition, or is it speculative? �In particular, if the loop had kept >> going in the complainant's machine, would it have found another entry >> that worked better? > Real, seen-in-the-field. It would proceed and eventually find the guys > Berlin timezone (Central European, which comes after Central Brazilian > which is the one that was missing the entries). Ah, of course. People who actually wanted the Central Brazilian zone are screwed, but they're screwed anyway, and there's no need to also screw people who want a zone that happens to come later in the list. +1 for the patch then. > It does, however, turn out that the issue was fixed when he re-applied > the latest timezone update hotfix from microsoft, which appears to > rewrite that entire subkey. Not sure how well we can trust that though > - it's not like we're working off a documented key... In any case, we might as well make things smoother for people working with unpatched systems, if it's such a small change. 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 6 Apr 2010 18:02 Oh, another thought here: what is the effect of the combination of this with your other proposal to add more timezones to the list? In particular, what happens if we use the extended list in an unpatched system that doesn't know about those new zone names? I'm wondering if we *have* to make this change for that to behave sanely. We might also need to consider whether we want any log chatter in such a case. 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: Magnus Hagander on 6 Apr 2010 18:27 On Wed, Apr 7, 2010 at 00:02, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Oh, another thought here: what is the effect of the combination of this > with your other proposal to add more timezones to the list? In > particular, what happens if we use the extended list in an unpatched > system that doesn't know about those new zone names? I'm wondering > if we *have* to make this change for that to behave sanely. We might > also need to consider whether we want any log chatter in such a case. No, as long as the key *exists* we've always moved on to the next one if it didn't match. It's only when it doesn't exist at all that we aborted. And if the system doesn't know about those names, it'll never show up. We're mapping *from* windows to *us*. So if the zones aren't in windows at all, there is no way for windows to give us that name. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: [HACKERS] Missing win32 timezones Next: [HACKERS] pg_filedump strangeness |