In bug #6097,
http://archives.postgresql.org/pgsql-bugs/2011-07/msg00063.php
Maxim Boguk points out that the postmaster goes south when presented
with a new addition to the postgresql.conf file. The reason is this
code in ProcessConfigFile:
/* In SIGHUP cases in the postmaster, report changes */
if (context == PGC_SIGHUP && !IsUnderPostmaster)
{
const char *preval = GetConfigOption(item->name, false);
which is not imagining that the option could possibly not be there yet,
but in fact it might not be, as pointed out earlier in the same
function:
/*
* 2. There is no GUC entry. If we called set_config_option then
* it would make a placeholder, which we don't want to do yet,
* since we could still fail further down the list. Do nothing
* (assuming that making the placeholder will succeed later).
*/
So it seems what we need is a no-fail version of GetConfigOption.
We could either add a "missing_ok" flag to that function or invent
a separate entry point to avoid touching existing callers. Since
this fix will have to be back-patched into 9.0, there is some merit
to doing the latter, but on the other hand I don't want to clutter
the API more. Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
