I came across a problem with the log_timezone patch. Given these
conditions:
* log_min_messages is at least debug3
* log_line_prefix includes %t or %m
* log_timezone is not explicitly set in postgresql.conf
the postmaster will dump core during startup, because it tries to format
an elog message using log_timezone while the variable is still NULL.
I can think of several ways of fixing this, but they all have drawbacks:
1. Tweak elog.c so that the timestamp-formatting escapes are disregarded
if log_timezone is still NULL. This is simple and robust, but some will
complain that early-startup messages are formatted differently from
those appearing later. I don't put a lot of weight on that, because
it is *necessarily* the case that messages appearing before GUCs are
all initialized will look different from those later. But it's a bit
annoying, and might be more than a bit annoying for CSV-format logging.
2. Tweak pg_localtime() so that it takes a null tz argument as meaning
GMT. I find this one pretty ugly --- it seems to remove a useful error
check even after startup. Also, it's not clear whether having messages
that are labeled in the wrong timezone is better or worse than not
labeling them at all. I'm also a bit worried whether invoking tzload()
too early in startup would work reliably.
3. Somehow rearrange the order of startup processing to guarantee that
log_timezone becomes set before log_line_prefix can be set. I thought
of a number of variants of this before realizing that any of them would
break the concern mentioned in postmaster.c:
* If timezone is not set, determine what the OS uses. (In theory this * should be done during GUC
initialization,but because it can take as * much as several seconds, we delay it until after we've created the *
postmaster.pidfile. This prevents problems with boot scripts that * expect the pidfile to appear quickly. Also, we
avoidproblems with * trying to locate the timezone files too early in initialization.)
This is what led us to run pg_timezone_initialize() as late as we do,
and I don't see any very good way around it. We could hack things so
that log_line_prefix doesn't become active until even later, but that
doesn't really improve matters in terms of having early-startup messages
be consistent with later ones.
I don't feel that we have to have a perfect solution to this, because
the messages in question will normally only be debugging ones. But we
definitely can't have it dumping core.
I'm leaning to solution #1 as being the simplest and least likely to
have unforeseen difficulties. I'm not sure if doing the same thing
in the CSV-log patch will be OK though. Comments?
regards, tom lane
