> > 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
