Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it
Date
Msg-id 10607.1390404395@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Noah Misch
Date:
Subject: Re: Dynamic Shared Memory stuff
Next
From: Alvaro Herrera
Date:
Subject: Re: Funny representation in pg_stat_statements.query.