Re: Issue with PGC_BACKEND parameters
От | Amit Kapila |
---|---|
Тема | Re: Issue with PGC_BACKEND parameters |
Дата | |
Msg-id | CAA4eK1Jw8KC+XGOtXb_k6Smch7hOZkoitqEQ=3Sop_U=zqbpNg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Issue with PGC_BACKEND parameters (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Issue with PGC_BACKEND parameters
|
Список | pgsql-hackers |
On Fri, Jan 31, 2014 at 2:01 AM, Andrew Dunstan <andrew@dunslane.net> wrote: > > On 01/30/2014 03:12 PM, Tom Lane wrote: >> >> Andrew Dunstan <andrew@dunslane.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
Вложения
В списке pgsql-hackers по дате отправления: