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
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. |