Re: Problem with log_timezone not being set during early startup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problem with log_timezone not being set during early startup
Date
Msg-id 17515.1186245992@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem with log_timezone not being set during early startup  (Decibel! <decibel@decibel.org>)
Responses Re: Problem with log_timezone not being set during early startup  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
Decibel! <decibel@decibel.org> writes:
> Something else to consider... normally you'd have to have a pretty
> serious condition to run into this in normal usage, right? (I doubt
> there's many folks that use any debug level, let alone 3) I think that
> gives us more flexibility.

Yeah.  This whole issue will really only affect developers, except for
cases where startup fails completely.

I complained earlier that tzload() might be unsafe if invoked too early,
but actually there's a worse issue, which is circularity: it's far from
clear that that code path cannot invoke elog itself. (Even if it doesn't
today, someone might innocently stick a debugging elog into someplace
like get_share_path.)  This could be worked around, with some hack on
the order of forcing GMT zone to be loaded before we begin GUC
initialization, but I'm really wondering how much work we want to put
into a marginal nicety.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: Problem with log_timezone not being set during early startup
Next
From: Decibel!
Date:
Subject: Re: Problem with log_timezone not being set during early startup