Re: Issue with PGC_BACKEND parameters - Mailing list pgsql-hackers

On 12/22/2013 11:30 PM, Amit Kapila wrote:
>> I had observed one problem with PGC_BACKEND parameters while testing patch
>> for ALTER SYSTEM command.
>> Problem statement: If I change PGC_BACKEND parameters directly in
>> postgresql.conf and then do pg_reload_conf() and reconnect, it will
>>                    still show the old value.
>> Detailed steps
>> 1. Start server with default settings
>> 2. Connect Client
>> 3. show log_connections; -- it will show as off, this is correct.
>> 4. Change log_connections in postgresql.conf to on
>> 5. issue command select pg_reload_conf() in client (which is started in step-2)
>> 6. Connect a new client
>> 7. show log_connections; -- it will show as off, this is "in-correct".
>> The problem is in step-7, it should show as on.
>> This problem occur only in Windows.
>> The reason for this problem is that in WINDOWS, when a new session is
>> started it will load the changed parameters in new backend by
>> global/config_exec_params file. The flow is in
>> SubPostmasterMain()->read_nondefault_variables()->set_config_option().
>> In below code in function set_config_option(), it will not allow to change
>> PGC_BACKEND variable and even in comments it has mentioned that only
>> postmaster will be allowed to change and the same will propagate to
>> subsequently started backends, but this is not TRUE for Windows.
>> switch (record->context)
>> {
>> ..
>> ..
>> case PGC_BACKEND:
>>                        if (context == PGC_SIGHUP)
>>                        {
>>                                /*
>>                                 * If a PGC_BACKEND parameter is changed in
>> the config file,
>>                                 * we want to accept the new value in the
>> postmaster (whence
>>                                 * it will propagate to subsequently-started
>> backends), but
>>                                 * ignore it in existing backends.
>> This is a tad klugy, but
>>                                 * necessary because we don't re-read the
>> config file during
>>                                 * backend start.
>>                                 */
>>                                if (IsUnderPostmaster)
>>                                        return -1;
>>                        }
>> }
>
>> I think to fix the issue we need to pass the information whether PGC_BACKEND
>> parameter is allowed to change in set_config_option() function.
>> One way is to pass a new parameter.
> Yesterday, I again thought about this issue and found that we can handle it by
> checking IsInitProcessingMode() which will be True only during backend startup
> which is what we need here.
>
> Please find the attached patch to fix this issue.
>
> I think that this issue should be fixed in PostgreSQL, because
> currently PGC_BACKEND
> parameters doesn't work on Windows.
>
>
>

--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -5605,9 +5605,12 @@ set_config_option(const char *name, const char 
*value,                  * it will propagate to subsequently-started 
backends), but                  * ignore it in existing backends.    This is a tad 
klugy, but                  * necessary because we don't re-read the config file 
during
-                 * 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;             }
   else if (context != PGC_POSTMASTER && context != 
 
PGC_BACKEND &&




I think this change looks OK. Does anyone else have any comments before 
I test and apply it? I presume it's a bugfix that should be backpatched.

cheers

andrew