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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it
Дата
Msg-id CAA4eK1+jjsshvQF7mTR6nV1j3=-R5AJaac3MePSO=J9NZCRzjQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Jan 21, 2014 at 8:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jan 17, 2014 at 12:07 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Fri, Jan 17, 2014 at 12:16 AM, Tom Lane <tgl@sss.pgh.pa.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



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Funny representation in pg_stat_statements.query.
Следующее
От: Jon Nelson
Дата:
Сообщение: Re: PoC: Duplicate Tuple Elidation during External Sort for DISTINCT