Tom Lane wrote:
> 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.
Any way to tweak this place and have it log in GMT instead, when
log_timezone is NULL? That way it would only change the early startup
messages (thus avoiding the concern in #2), but it'd still show the
timezone (different from the system, but it'd be something
deterministic). I think that's better than just dropping the TZ information.
If not, I still agree with you that #1 is the best way to go from these.
> 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.
Depends on what you mean with "wrong timezone". If they're labelled with
a timezone that's not the same as the time is in, then it's very very
bad because it gives you the wrong time. If you mean labeling them as
GMT when the user expected EST (or whatever), think that's better than
no TZ at all - as long as we specify the TZ, the time is exact, even if
the user may need to do some calculations to figure out it in the local one.
I do agree that removing that error check is bad.
//Magnus
