API for GetConfigOption()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: API for GetConfigOption()
Date: 2011-07-08 15:35:25
Message-ID: 27875.1310139325@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-07-08 15:38:51 Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.
Previous Message Robert Haas 2011-07-08 15:32:47 Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.