Re: Server does not start when log_statement_stats is set to on

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Server does not start when log_statement_stats is set to on
Дата
Msg-id 12041.1198704616@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Server does not start when log_statement_stats is set to on  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Server does not start when log_statement_stats is set to on  (Alvaro Herrera <alvherre@CommandPrompt.com>)
Re: Server does not start when log_statement_stats is set to on  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-bugs
I wrote:
> The whole idea sounds pretty shaky to me, and definitely not
> something to change in late beta.  LOG we could do now without
> risking breaking anything.

Poking around a bit more, I notice that there are already some places
that do it the way I was thinking of, eg in commands/variable.c:

            if (!new_tz)
            {
                ereport((source >= PGC_S_INTERACTIVE) ? ERROR : LOG,
                        (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                         errmsg("unrecognized time zone name: \"%s\"",
                                value)));
                return NULL;
            }

However, even this is not really good enough: in the event of a wrong
entry inserted into postgresql.conf, this coding will result in every
extant backend emitting the same LOG message at SIGHUP.  That's
annoying.  The right way to do it is as illustrated in
set_config_option(): only the postmaster should log at LOG level,
everyone else should be down around DEBUG2 (if not lower).

That's getting to be a bit complicated to replicate in N places, though.
Plus if we ever want to make it work like Alvaro is thinking of, we'd
have to go back and change all those places again.  So I propose
inventing a function

    int guc_complaint_level(GucSource source)

that encapsulates this logic.  The correct coding for specialized
error messages in assign-hook routines would then be like

            if (!new_tz)
            {
                ereport(guc_complaint_level(source),
                        (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
                         errmsg("unrecognized time zone name: \"%s\"",
                                value)));
                return NULL;
            }

giving us only one place to change to alter this logic.

Comments, objections?

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Server does not start when log_statement_stats is set to on
Следующее
От: Tomas Szepe
Дата:
Сообщение: 8.3beta4: pg_dump tab escape change