On Thu, 25 Aug 2005, Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> The most unambiguous behavior would be to not have
>> commented out values in the config file at all.
>
> Yeah, Robert Treat suggested that upthread, and I think it's been pushed
> by others too.
>
> The only argument I can see against it is that it'll take longer for the
> system to process such a file; but do we really care about a few more
> microseconds to respond to SIGHUP?
This has probably been mentioned already, but it makes it much harder to
see which values have been altered from their default values. At the very
least, the default values should be in the comments together with the min
and max values.
Also, suppose that we change the default value of parameter in a new
release. That change wouldn't be picked up by upgraders that keep using
their old config file. I don't know how big an issue that is in practice.
We could have a special value DEFAULT that would mean that the variable
should be set to it's default. The config file would look like this:
shared_buffers = DEFAULT # default 1000
work_mem = DEFAULT # default 1024
...
That would avoid the surprise that commenting a line and reloading
doesn't actually do anything, while also making it obvious which values
have been modified.
> This does not address the problem that changing PGC_POSTMASTER values in
> the file won't do anything without a postmaster restart. Greg Stark's
> suggestion of marking each PGC_POSTMASTER variable with a warning
> comment in postgresql.conf seems reasonable to me, though.
If we keep the current behaviour, could we also issue a runtime warning if
a PGC_POSTMASTER variable was changed? Also, could we issue a warning if a
variable is not at it's default value, but is missing from the new
config file?
- Heikki
