From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, Hari Babu <haribabu(dot)kommi(at)huawei(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER SYSTEM SET command to change postgresql.conf parameters |
Date: | 2014-01-10 04:06:38 |
Message-ID: | CAA4eK1LYxUQ+DFjicNo4odQSSn5oi0KonQA8gYy7RpygS1Z0Vg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 9, 2014 at 12:26 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Jan 6, 2014 at 11:37 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> On Tue, Jan 7, 2014 at 12:52 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Mon, Jan 6, 2014 at 9:48 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>>>> Couldn't we also handle this by postponing FreeConfigVariables until
>>>>> after the if (error) block?
>>>>
>>>> Wouldn't doing that way can lead to bigger memory leak, if error level
>>>> is ERROR. Though in current fix also it can leak memory but it will be
>>>> just for ErrorConfFile_save. I think some similar case can happen for
>>>> 'pre_value' in code currently as well, that's why I have fixed it in a
>>>> similar way in patch.
>>>
>>> I was assuming that error-recovery would reset the containing memory
>>> context, but I'm not sure what memory context we're executing in at
>>> this point.
>>
>>
>> In current code, the only time it can go to error path with elevel as
>> ERROR is during Postmaster startup
>> (context == PGC_POSTMASTER), at which it will anyway upgrade
>> ERROR to FATAL, so it should not be a problem to move
>> function FreeConfigVariables() after error block check. However
>> in future, if someone added any more ERROR (the chances of which
>> seems to be quite less), it can cause leak, may be thats why original
>> code has been written that way.
>>
>> If you think it's better to fix by moving FreeConfigVariables() after error
>> block check, then I can update the patch by doing so and incorporate other
>> change (directly use PG_AUTOCONF_FILENAME) suggested by you
>> as well?
>
> Yeah, let's do it that way.
Okay, done. Attached patch fixes both the display of wrong file name and
usage of PG_AUTOCONF_FILENAME.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
display_error_conf_filename_v2.patch | application/octet-stream | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-01-10 04:07:52 | Re: Bogus error handling in pg_upgrade |
Previous Message | Etsuro Fujita | 2014-01-10 03:57:02 | Re: Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan |