Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it
Дата
Msg-id 10607.1390404395@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Tue, Jan 21, 2014 at 8:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> While reviewing, I noted that the
>> "skipping missing configuration file" message in ParseConfigFile()
>> uses an elevel of LOG, while the other messages in the same file use
>> "elevel".  I'm thinking that's a bug.

> It might not be right for all cases, but I think this is saving us in few cases
> when the caller (directly or indirectly) has sent elevel as ERROR or FATAL,
> in such cases we just want to LOG it, if strict is not true. Now it might not
> be appropriate if the caller has sent DEBUG2 and we use LOG, but to
> fix it (if this sounds an issue), some more analysis is required, so let's
> keep it as it is for now.

The problem with this coding is that at SIGHUP, *all* the postgres
processes will bleat about a missing file.

To avoid that kind of log spam, the usual practice is to code the
elog level as something like "IsUnderPostmaster ? DEBUG2 : LOG";
see the elevel setting in ProcessConfigFile() for precedent.
In fact, I'm pretty sure that the elevel passed to ParseConfigFile
should always have come from that logic.

In any case, your argument is bogus because we could already have
thrown an error at the given elevel further up in ParseConfigFile,
or later in ParseConfigFp.  None of this code is meant to receive
an ERROR-or-higher elevel.

So yes, this is broken and needs to be changed as Robert says.
        regards, tom lane



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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: Dynamic Shared Memory stuff
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Funny representation in pg_stat_statements.query.