Defaults for GUC variables (was Re: pg_ctl reports succes when start fails) - Mailing list pgsql-hackers

From Tom Lane
Subject Defaults for GUC variables (was Re: pg_ctl reports succes when start fails)
Date
Msg-id 29413.1067268152@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_ctl reports succes when start fails  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: Defaults for GUC variables (was Re: pg_ctl reports
Re: Defaults for GUC variables (was Re: pg_ctl reports
Re: Defaults for GUC variables (was Re: pg_ctl reports succes when start fails)
List pgsql-hackers
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
>>> The latter...why won't it affect the postmaster state?
>> 
>> Because it's a *comment*.

> Shouldn't it revert to the default value?

No, not unless you think the postmaster should react to comments in the
postgresql.conf file, which is rather against my idea of a comment.

However, you're not the first to get burnt by this mis-assumption,
so maybe we should do something about it.

The low-tech solution to this would be to stop listing the default
values as commented-out entries, but just make them ordinary uncommented
entries.  That way people who think "undoing my edit will revert the
change" would be right.

Or we could try to make it actually work the way you seem to be
expecting.  The only implementation I can think of is to reset GUC
variables to defaults just before scanning the .conf file (but only
if their prior value came from the .conf file, which fortunately is
something we keep track of).  The trouble with this is that any error
in scanning the .conf file could leave you with unexpectedly reverted
values for later entries, because they'd not be reached.

Or we could just document the behavior better...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Aggregate detoasted arguments lifetime
Next
From: Bruce Momjian
Date:
Subject: Re: Still a few flaws in configure's default CFLAGS selection