Re: [HACKERS] Win32 timezone matching
On Thu, Apr 15, 2010 at 2:54 AM, Tom Lane t...@sss.pgh.pa.us wrote: [ back to this... ] Magnus Hagander mag...@hagander.net writes: On Wed, Apr 7, 2010 at 21:06, Tom Lane t...@sss.pgh.pa.us wrote: I suppose we had a reason for doing it the first way but I can't see what. GMT seems a fairly English-centric way of referring to UTC anyhow; translators might wish to put in UTC instead, or some other spelling. Shouldn't we let them? UTC and GMT aren't actually the same thing. Tell it to the zic people --- they are identical except for the zone abbreviation itself, according to the zic database. There might be some pedantic argument for preferring the name UTC, but I'm hesitant to change that behavior just to satisfy pedants. Agreed, I don't think it's worth changing. However, that also goes to the translation of it - let's keep *one* term, that'll make it a lot less confusing. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
On Thu, Apr 15, 2010 at 3:48 AM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Wed, Apr 7, 2010 at 21:01, Tom Lane t...@sss.pgh.pa.us wrote: ... lack either the note about defaulting to GMT or the hint. I guess we should add both of those to the failure cases in the Windows version of identify_system_timezone. Should we also change the WARNING errlevel to LOG? I think the latter is more likely to actually get into the log. You are suggesting adding this after the could not find match message, correct? Not replacing it? Because if we replace it, we loose the information of what we failed to match. So basically like attached? No, I was thinking more like the attached. This changes the Unix code to separate the info about the fallback timezone into errdetail, and then makes the Windows messages follow that style. Yeah, that looks good. Also, would LOG be *more* likely to be seen than a WARNING? Why would that be? Because that's how log levels sort for the postmaster log. This isn't an interactive warning --- we will never be executing this code in a regular backend, only in the postmaster. Well, when the dba looks through the log, he'll be looking a lot harder at something that says WARNING. And if somebody is filtering his log so hard that it doesn't even contain WARNING's, frankly, he's ignorant ;) But that's just me, and I've never really agreed with that soring in the first place, so maybe I should just be ignored... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
[ back to this... ] Magnus Hagander mag...@hagander.net writes: On Wed, Apr 7, 2010 at 21:06, Tom Lane t...@sss.pgh.pa.us wrote: I suppose we had a reason for doing it the first way but I can't see what. GMT seems a fairly English-centric way of referring to UTC anyhow; translators might wish to put in UTC instead, or some other spelling. Shouldn't we let them? UTC and GMT aren't actually the same thing. Tell it to the zic people --- they are identical except for the zone abbreviation itself, according to the zic database. There might be some pedantic argument for preferring the name UTC, but I'm hesitant to change that behavior just to satisfy pedants. And either way, it's an abbreviation, and we don't normally translate those, do we? I think that might in fact have been the argument for the current coding style; but it still seems like it's overcomplicating matters in order to prevent translators from making a decision they should be perfectly competent to make for themselves. Anyway, it's not real important. Since nobody else seems to be excited about changing that part, I'll leave it alone. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
Magnus Hagander mag...@hagander.net writes:
On Wed, Apr 7, 2010 at 21:01, Tom Lane t...@sss.pgh.pa.us wrote:
... lack either the note about defaulting to GMT or the hint. I guess
we should add both of those to the failure cases in the Windows version
of identify_system_timezone. Should we also change the WARNING errlevel
to LOG? I think the latter is more likely to actually get into the log.
You are suggesting adding this after the could not find match
message, correct? Not replacing it? Because if we replace it, we loose
the information of what we failed to match. So basically like
attached?
No, I was thinking more like the attached. This changes the Unix code
to separate the info about the fallback timezone into errdetail, and
then makes the Windows messages follow that style.
Also, would LOG be *more* likely to be seen than a WARNING? Why would that be?
Because that's how log levels sort for the postmaster log. This isn't
an interactive warning --- we will never be executing this code in a
regular backend, only in the postmaster.
regards, tom lane
Index: pgtz.c
===
RCS file: /cvsroot/pgsql/src/timezone/pgtz.c,v
retrieving revision 1.71
diff -c -r1.71 pgtz.c
*** pgtz.c 9 Apr 2010 11:49:51 - 1.71
--- pgtz.c 15 Apr 2010 01:40:39 -
***
*** 498,505
if (std_zone_name[0] == '\0')
{
ereport(LOG,
! (errmsg(could not determine system time zone, defaulting to \%s\, GMT),
! errhint(You can specify the correct timezone in postgresql.conf.)));
return NULL; /* go to GMT */
}
--- 498,507
if (std_zone_name[0] == '\0')
{
ereport(LOG,
! (errmsg(could not determine system time zone),
! errdetail(The PostgreSQL time zone will be set to \%s\.,
! GMT),
! errhint(You can specify the correct timezone in postgresql.conf.)));
return NULL; /* go to GMT */
}
***
*** 533,541
(-std_ofs 0) ? + : , -std_ofs / 3600);
ereport(LOG,
! (errmsg(could not recognize system timezone, defaulting to \%s\,
! resultbuf),
! errhint(You can specify the correct timezone in postgresql.conf.)));
return resultbuf;
}
--- 535,544
(-std_ofs 0) ? + : , -std_ofs / 3600);
ereport(LOG,
! (errmsg(could not recognize system timezone),
! errdetail(The PostgreSQL time zone will be set to \%s\.,
! resultbuf),
! errhint(You can specify the correct timezone in postgresql.conf.)));
return resultbuf;
}
***
*** 1076,1084
if (!tm)
{
! ereport(WARNING,
! (errmsg_internal(could not determine current date/time: localtime failed)));
! return NULL;
}
memset(tzname, 0, sizeof(tzname));
--- 1079,1090
if (!tm)
{
! ereport(LOG,
! (errmsg(could not identify system time zone: localtime() failed),
! errdetail(The PostgreSQL time zone will be set to \%s\.,
! GMT),
! errhint(You can specify the correct timezone in postgresql.conf.)));
! return NULL; /* go to GMT */
}
memset(tzname, 0, sizeof(tzname));
***
*** 1089,1095
if (strcmp(tzname, win32_tzmap[i].stdname) == 0 ||
strcmp(tzname, win32_tzmap[i].dstname) == 0)
{
! elog(DEBUG4, TZ \%s\ matches Windows timezone \%s\,
win32_tzmap[i].pgtzname, tzname);
return win32_tzmap[i].pgtzname;
}
--- 1095,1101
if (strcmp(tzname, win32_tzmap[i].stdname) == 0 ||
strcmp(tzname, win32_tzmap[i].dstname) == 0)
{
! elog(DEBUG4, TZ \%s\ matches system time zone \%s\,
win32_tzmap[i].pgtzname, tzname);
return win32_tzmap[i].pgtzname;
}
***
*** 1107,1115
KEY_READ,
rootKey) != ERROR_SUCCESS)
{
! ereport(WARNING,
! (errmsg_internal(could not open registry key to identify Windows timezone: %i, (int) GetLastError(;
! return NULL;
}
for (idx = 0;; idx++)
--- 1113,1125
KEY_READ,
rootKey) != ERROR_SUCCESS)
{
! ereport(LOG,
! (errmsg(could not open registry key to identify system time zone: %i,
! (int) GetLastError()),
! errdetail(The PostgreSQL time zone will be set to \%s\.,
! GMT),
! errhint(You can specify the correct timezone in postgresql.conf.)));
! return NULL; /* go to GMT */
}
for (idx = 0;; idx++)
***
*** 1134,1148
{
if (r == ERROR_NO_MORE_ITEMS)
break;
! ereport(WARNING,
! (errmsg_internal(could not enumerate registry subkeys to identify Windows timezone: %i, (int) r)));
break;
}
if ((r = RegOpenKeyEx(rootKey, keyname, 0, KEY_READ, key)) != ERROR_SUCCESS)
{
! ereport(WARNING,
! (errmsg_internal(could not open registry subkey to identify Windows timezone: %i, (int) r)));
break;
}
--- 1144,1158
{
if (r == ERROR_NO_MORE_ITEMS)
break;
! ereport(LOG,
!
Re: [HACKERS] Win32 timezone matching
On Wed, Apr 7, 2010 at 00:48, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Wed, Apr 7, 2010 at 00:02, Tom Lane t...@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? I've applied the patch to add the missing timezone names. Before I did that I wrote a small perlscript that reads pgtz.c and compares what's there to what's in the registry of the current machine. Turns out I had missed one, which is Argentina Standard Time. This script should probably live in CVS, and be run when Microsoft releases new timezone data. Where should I put it - src/timezone or somewhere in src/tools? (it does read pgtz.c in the current directory, but it doesn't actually edit the file - just outputs on stdout a list of changes to be made to the file manually) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
On Wed, Apr 7, 2010 at 21:06, Tom Lane t...@sss.pgh.pa.us wrote: I wrote: ereport(LOG, (errmsg(could not determine system time zone, defaulting to \%s\, GMT), BTW, does anyone remember the reason for making GMT nonlocalizable in these messages? It seems more straightforward to do Nope, can't recall that. (errmsg(could not determine system time zone, defaulting to \GMT\), I suppose we had a reason for doing it the first way but I can't see what. GMT seems a fairly English-centric way of referring to UTC anyhow; translators might wish to put in UTC instead, or some other spelling. Shouldn't we let them? UTC and GMT aren't actually the same thing. In fact, it might be more sensible to fall back to UTC than GMT. Both in the message *and* the code, in that case. They only differ in fractions of seconds, but we do deal in fractions of seconds... It also carries the nice property that it's *supposed* to be abbreviated the same way regardless of language (which is why it's UTC and not CUT). And either way, it's an abbreviation, and we don't normally translate those, do we? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
On Wed, Apr 7, 2010 at 21:01, Tom Lane t...@sss.pgh.pa.us wrote: Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes: Even if if keep the current fallback behaviour we should at least fix the windows codepath to do the same as the unix codepath does - as in actually logging that the fallback to GMT happened... +1 for that anyway. There already are WARNING messages for the various Windows failure cases, but compared to the Unix code ereport(LOG, (errmsg(could not determine system time zone, defaulting to \%s\, GMT), errhint(You can specify the correct timezone in postgresql.conf.))); they lack either the note about defaulting to GMT or the hint. I guess we should add both of those to the failure cases in the Windows version of identify_system_timezone. Should we also change the WARNING errlevel to LOG? I think the latter is more likely to actually get into the log. You are suggesting adding this after the could not find match message, correct? Not replacing it? Because if we replace it, we loose the information of what we failed to match. So basically like attached? Also, would LOG be *more* likely to be seen than a WARNING? Why would that be? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ win32_tz_warning.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
On Wed, Apr 7, 2010 at 00:48, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Wed, Apr 7, 2010 at 00:02, Tom Lane t...@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? [ none ] Ah, right, I hadn't looked closely at the logic before. Still have two comments though: * There are other error conditions that cause breaks in that loop. Should we change the others? The only other error condition is if we find a key but can't open it. That indicates something that's *seriously* wrong, so I'm inclined to keep that one. The other two break statements are actually for when we *find* a match, so they just indicate that we pick the first match that we find. * There is a comment at the head of win32_tzmap[] explaining where the data came from; you need to update that. Right. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
Magnus Hagander wrote: On Wed, Apr 7, 2010 at 00:48, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Wed, Apr 7, 2010 at 00:02, Tom Lane t...@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? [ none ] Ah, right, I hadn't looked closely at the logic before. Still have two comments though: * There are other error conditions that cause breaks in that loop. Should we change the others? The only other error condition is if we find a key but can't open it. That indicates something that's *seriously* wrong, so I'm inclined to keep that one. The other two break statements are actually for when we *find* a match, so they just indicate that we pick the first match that we find. hmm all that code makes me wonder a bit about a more general issue - is the fallback to GMT if we fail to actually make sense of the right imezone to use actually a good idea? In the case of the person I helped diagnosing the issue pg was bundled into some commercial app and the only reason the user immediately noticed that something was wrong was because the app used something like select now() to display the current time in the GUI. I would consider the failure to make sense of the registry on windows or failure to figure timezone information out a more serious issue than a mere WARNING because depending on how you look at the issue it might actually cause silent data corruption. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes: hmm all that code makes me wonder a bit about a more general issue - is the fallback to GMT if we fail to actually make sense of the right imezone to use actually a good idea? What alternative are you proposing? Failing to start the server doesn't seem like an attractive choice. I would consider the failure to make sense of the registry on windows or failure to figure timezone information out a more serious issue than a mere WARNING because depending on how you look at the issue it might actually cause silent data corruption. Somehow, if you're running a database on windoze, I doubt your data integrity standards are that high. In any case I'd rather get a bleat about why is the server running in GMT than my database won't start. The former will be a lot easier to narrow down. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
Tom Lane wrote: Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes: hmm all that code makes me wonder a bit about a more general issue - is the fallback to GMT if we fail to actually make sense of the right imezone to use actually a good idea? What alternative are you proposing? Failing to start the server doesn't seem like an attractive choice. why not? we do error out in a lot of other cases as well... Personally I find a hard and clear something is wrong please fix much more convinient than defaulting to something that is more or less completely arbitrary but well... I would consider the failure to make sense of the registry on windows or failure to figure timezone information out a more serious issue than a mere WARNING because depending on how you look at the issue it might actually cause silent data corruption. Somehow, if you're running a database on windoze, I doubt your data integrity standards are that high. In any case I'd rather get a bleat about why is the server running in GMT than my database won't start. The former will be a lot easier to narrow down. heh - except that we fail in that department - The only (not really useful hint) that pg logged was: WARNUNG: could not query value for 'std' to identify Windows timezone: 2 which says nothing about I failed to figure something sane out and so I have to fallback to GMT (which is what the !WIN32 code path seems to be actually doing but not the WIN32 code). And even from the vendor perspective getting a support call on uhm the database for your app is not starting what logs should I look at seems better than hmm we are now 2 weeks in production and just noticed that all the timestamps are off by a few hours how can we fix our data?. PostgreSQL is bundled with a lot of apps on windows these days so the enduser might not even aware of it (and look into the eventlog only to find a rather oddly phrased WARNING) unless it fails hard... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
On Wed, Apr 7, 2010 at 12:20 PM, Stefan Kaltenbrunner ste...@kaltenbrunner.cc wrote: Tom Lane wrote: Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes: hmm all that code makes me wonder a bit about a more general issue - is the fallback to GMT if we fail to actually make sense of the right imezone to use actually a good idea? What alternative are you proposing? Failing to start the server doesn't seem like an attractive choice. why not? we do error out in a lot of other cases as well... Personally I find a hard and clear something is wrong please fix much more convinient than defaulting to something that is more or less completely arbitrary but well... While I can understand why someone might want that behavior in some cases, in other cases it might be a severe overreaction. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
On Wed, Apr 7, 2010 at 7:04 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Apr 7, 2010 at 12:20 PM, Stefan Kaltenbrunner ste...@kaltenbrunner.cc wrote: Tom Lane wrote: Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes: hmm all that code makes me wonder a bit about a more general issue - is the fallback to GMT if we fail to actually make sense of the right imezone to use actually a good idea? What alternative are you proposing? Failing to start the server doesn't seem like an attractive choice. why not? we do error out in a lot of other cases as well... Personally I find a hard and clear something is wrong please fix much more convinient than defaulting to something that is more or less completely arbitrary but well... While I can understand why someone might want that behavior in some cases, in other cases it might be a severe overreaction. I think the dangerous scenario is if it worked, and then stopped working. In that case, the database will change it's behavior and it might go unnoticed. If it's wrong on first install, it'll likely get noticed.. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
Magnus Hagander wrote: On Wed, Apr 7, 2010 at 7:04 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Apr 7, 2010 at 12:20 PM, Stefan Kaltenbrunner ste...@kaltenbrunner.cc wrote: Tom Lane wrote: Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes: hmm all that code makes me wonder a bit about a more general issue - is the fallback to GMT if we fail to actually make sense of the right imezone to use actually a good idea? What alternative are you proposing? Failing to start the server doesn't seem like an attractive choice. why not? we do error out in a lot of other cases as well... Personally I find a hard and clear something is wrong please fix much more convinient than defaulting to something that is more or less completely arbitrary but well... While I can understand why someone might want that behavior in some cases, in other cases it might be a severe overreaction. I think the dangerous scenario is if it worked, and then stopped working. In that case, the database will change it's behavior and it might go unnoticed. If it's wrong on first install, it'll likely get noticed.. yeah that is one aspect - and in talking to the OP he would have prefered the database not starting up at all, logging an error and a hint on setting a fixed timezone in the conf. Even if if keep the current fallback behaviour we should at least fix the windows codepath to do the same as the unix codepath does - as in actually logging that the fallback to GMT happened... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes: yeah that is one aspect - and in talking to the OP he would have prefered the database not starting up at all, logging an error and a hint on setting a fixed timezone in the conf. Well, you started from the statement that this was an embedded copy of postgres ... so most users might not even know it was there, much less to check its postmaster log for problems. I'm still of the opinion that refusing to start is an overreaction. Even if if keep the current fallback behaviour we should at least fix the windows codepath to do the same as the unix codepath does - as in actually logging that the fallback to GMT happened... +1 for that anyway. There already are WARNING messages for the various Windows failure cases, but compared to the Unix code ereport(LOG, (errmsg(could not determine system time zone, defaulting to \%s\, GMT), errhint(You can specify the correct timezone in postgresql.conf.))); they lack either the note about defaulting to GMT or the hint. I guess we should add both of those to the failure cases in the Windows version of identify_system_timezone. Should we also change the WARNING errlevel to LOG? I think the latter is more likely to actually get into the log. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
I wrote: ereport(LOG, (errmsg(could not determine system time zone, defaulting to \%s\, GMT), BTW, does anyone remember the reason for making GMT nonlocalizable in these messages? It seems more straightforward to do (errmsg(could not determine system time zone, defaulting to \GMT\), I suppose we had a reason for doing it the first way but I can't see what. GMT seems a fairly English-centric way of referring to UTC anyhow; translators might wish to put in UTC instead, or some other spelling. Shouldn't we let them? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Win32 timezone matching
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. Comments? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ win32_tzskip.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
Magnus Hagander mag...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
On Tue, Apr 6, 2010 at 23:44, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
Magnus Hagander mag...@hagander.net writes: On Tue, Apr 6, 2010 at 23:44, Tom Lane t...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
On Wed, Apr 7, 2010 at 00:02, Tom Lane t...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Win32 timezone matching
Magnus Hagander mag...@hagander.net writes: On Wed, Apr 7, 2010 at 00:02, Tom Lane t...@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? [ none ] Ah, right, I hadn't looked closely at the logic before. Still have two comments though: * There are other error conditions that cause breaks in that loop. Should we change the others? * There is a comment at the head of win32_tzmap[] explaining where the data came from; you need to update that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
