Fix processing of PGC_BACKEND GUC parameters on Windows.

EXEC_BACKEND builds (i.e., Windows) failed to absorb values of PGC_BACKEND
parameters if they'd been changed post-startup via the config file.  This
for example prevented log_connections from working if it were turned on
post-startup.  The mechanism for handling this case has always been a bit
of a kluge, and it wasn't revisited when we implemented EXEC_BACKEND.
While in a normal forking environment new backends will inherit the
postmaster's value of such settings, EXEC_BACKEND backends have to read
the settings from the CONFIG_EXEC_PARAMS file, and they were mistakenly
rejecting them.  So this case has always been broken in the Windows port;
so back-patch to all supported branches.

Amit Kapila
This commit is contained in:
Tom Lane 2014-04-05 12:41:25 -04:00
parent 44c5d387ea
commit 6862ca6970

View File

@ -5669,9 +5669,23 @@ set_config_option(const char *name, const char *value,
* ignore it in existing backends. This is a tad klugy, but
* necessary because we don't re-read the config file during
* backend start.
*
* In EXEC_BACKEND builds, this works differently: we load all
* nondefault settings from the CONFIG_EXEC_PARAMS file during
* backend start. In that case we must accept PGC_SIGHUP
* settings, so as to have the same value as if we'd forked
* from the postmaster. We detect this situation by checking
* IsInitProcessingMode, which is a bit ugly, but it doesn't
* seem worth passing down an explicit flag saying we're doing
* read_nondefault_variables().
*/
#ifdef EXEC_BACKEND
if (IsUnderPostmaster && !IsInitProcessingMode())
return -1;
#else
if (IsUnderPostmaster)
return -1;
#endif
}
else if (context != PGC_POSTMASTER && context != PGC_BACKEND &&
source != PGC_S_CLIENT)
@ -8310,6 +8324,12 @@ read_nondefault_variables(void)
GucSource varsource;
GucContext varscontext;
/*
* Assert that PGC_BACKEND case in set_config_option() will do the right
* thing.
*/
Assert(IsInitProcessingMode());
/*
* Open file
*/