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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it
Date: 2014-01-22 05:00:44
Message-ID: CAA4eK1+jjsshvQF7mTR6nV1j3=-R5AJaac3MePSO=J9NZCRzjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 21, 2014 at 8:25 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Jan 17, 2014 at 12:07 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> On Fri, Jan 17, 2014 at 12:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> PS: off topic, but isn't ParseConfigDirectory leaking the result
>>> of AbsoluteConfigLocation? In both normal and error paths?
>>
>> Yes, I also think it leaks in both cases and similar leak is
>> present in ParseConfigFile(). I have tried to fix both of these
>> leaks with attached patch.
>
> Committed and back-patched to 9.3.
Thanks.

> 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.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jon Nelson 2014-01-22 05:07:00 Re: PoC: Duplicate Tuple Elidation during External Sort for DISTINCT
Previous Message Peter Geoghegan 2014-01-22 04:43:44 Re: Funny representation in pg_stat_statements.query.