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.pid file. This prevents problems with boot scripts that * expect the pidfile to appear quickly. Also, we avoid problems 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings