Andrew Dunstan <andrew@dunslane.net> writes:
> Something is surely wrong in the timezone lib, though:
[ digs in glibc sources for awhile... ]
The test loop in score_timezone() calls both localtime() and strftime()
for each probe point, and in glibc strftime() calls tzset(), which the
source code claims is required by POSIX. The explicit tzset() call is
what's forcing the recheck of /etc/localtime.
Possibly the glibc boys would listen to a suggestion that strftime()
need not force the file recheck, but my experience with them is that
they're relatively impervious to suggestions :-(
I'm not actually particularly worried about the startup time. What's
bothering me right at the moment, given the new-found knowledge that
strftime() is slow on Linux, is that we're using it in elog(). At the
time that code was written, we did it deliberately to ensure that all
the backends would write log timestamps in the same timezone regardless
of local SET TimeZone commands. That's still an important
consideration, but I wonder whether we don't now have enough timezone
infrastructure that we could get the same results using pg_strftime.
regards, tom lane
