From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Issue with PGC_BACKEND parameters |
Date: | 2014-01-31 03:54:48 |
Message-ID: | CAA4eK1Jw8KC+XGOtXb_k6Smch7hOZkoitqEQ=3Sop_U=zqbpNg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 31, 2014 at 2:01 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 01/30/2014 03:12 PM, Tom Lane wrote:
>>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>>
>>> On 12/22/2013 11:30 PM, Amit Kapila wrote:
>>> - * backend start.
>>> + * backend start. However for windows, we need to
>>> process
>>> + * config file during backend start for non-default
>>> parameters,
>>> + * so we need to allow change of PGC_BACKEND during
>>> backend
>>> + * startup.
>>> */
>>> - if (IsUnderPostmaster)
>>> + if (IsUnderPostmaster && !IsInitProcessingMode())
>>> return -1;
>>> }
>>> I think this change looks OK.
>>
>> The comment is pretty awful, since this is neither Windows-specific nor
>> a read of the config file. Perhaps more like "However, in EXEC_BACKEND
>> builds we load nondefault settings from the CONFIG_EXEC_PARAMS file during
>> backend start. In that situation we should accept PGC_SIGHUP
>> settings, so as to have the same value as if we'd forked from the
>> postmaster."
Changed as per suggestion.
>> Also, I think that the extra test should only be made #ifdef EXEC_BACKEND,
>> so as to minimize the risk of breaking things.
Agreed and changed the patch as per suggestion.
>>Not that this isn't pretty
>> darn fragile anyway; I think testing IsInitProcessingMode here is a very
>> random way to detect this case. I wonder if it'd be better to pass down
>> an explicit flag indicating that we're doing read_nondefault_variables().
My first idea was to add a parameter, but set_config_option is getting called
from multiple places and this case doesn't seem to be generic enough to
add a parameter to commonly used function, so I found another way of doing
it. I agree that adding a new parameter would be a better fix, but just seeing
the places from where it get called, I thought of doing it other way, however
if you feel strongly about it, I can change the patch to pass a new parameter
to set_config_option().
>> If we don't do that, maybe an Assert(IsInitProcessingMode()) in
>> read_nondefault_variables() would be a good thing.
Added Assert in read_nondefault_variables().
>
>
>
> OK, I've added your comment to the commitfest item and marked it as "Waiting
> on Author".
Thanks for Review.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
set_guc_backend_params_v2.patch | application/octet-stream | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-01-31 04:06:09 | Re: updated emacs configuration |
Previous Message | Bruce Momjian | 2014-01-31 03:44:21 | Re: pgindent behavior we could do without |