> > 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.
>
> If glibc fixes the problem upstream then we can leave well
> enough alone, but if they indicate they won't then we should
That'll take quite a while to trickle down into the distributions even
if it's fixed, won't it? If the fix is simple, we should perhaps
consider it anyway.
> think about doing this someday. The major problem with it
> probably is "what do you do when messages need to be emitted
> before pgtz has been initialized?"
Shouldn't be too hard, I think. If we declare a "pg_tz* system_timezone"
or so, and initialize it to NULL. Once pgtz is initialized we assign a
valid timezone to it, being the startup timezone. Then in elog, we
simply check if system_timezone is null and then fallback on the glibc
version of strftime.
It shouldn't be a performance issue if it fails that often, because we
won't call elog a whole lot of times there, right?
//Magnus