Re: Problem with log_timezone not being set during early startup

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Problem with log_timezone not being set during early startup
Дата
Msg-id 17515.1186245992@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Problem with log_timezone not being set during early startup  (Decibel! <decibel@decibel.org>)
Ответы Re: Problem with log_timezone not being set during early startup
Список 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 по дате отправления:

Предыдущее
От: Decibel!
Дата:
Сообщение: Re: Problem with log_timezone not being set during early startup
Следующее
От: Decibel!
Дата:
Сообщение: Re: Problem with log_timezone not being set during early startup