Re: postgresql.auto.conf and reload

On Sat, Jul 5, 2014 at 10:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
>> Please find the patch attached to address the above concern. I have
>> updated docs, so that users can be aware of such behaviour.
>
> I'm in the camp that says that we need to do something about this, not
> just claim that it's operating as designed. AFAICS, the *entire* argument
> for having ALTER SYSTEM at all is ease of use; but this behavior is not
> what I would call facilitating ease of use. In particular, if you are
> conveniently able to edit postgresql.conf, what the heck do you need
> ALTER SYSTEM for?
>
> One possible answer is to modify guc-file.l so that only the last value
> supplied for any one GUC gets processed. The naive way of doing that
> would be O(N^2) in the number of uncommented settings, which might or
> might not be a problem; if it is, we could no doubt devise a smarter
> data structure.

I've been really annoyed by the current behavior even on older
releases because I have a script, which I use frequently, that does
this:

initdb
cat >> $PGDATA/postgresql.conf <<EOM
shared_buffers=8GB
another setting
another setting
another setting
EOM

Now, sometimes while experimenting, I will change a setting in
postgresql.conf and reload the config. At which point it complains
that it can't change shared_buffers at runtime. It does this because
the line from initdb is in the file, and so is the one I added. But
I'm *not* trying to change shared_buffers. Sure, the first value in
the config file doesn't match the current value, but the *last* line
in the config file is the one that's supposed to control, so why is it
complaining about the earlier line?

I haven't looked at the code in this area too carefully, but it seems
to me like the flow ought to be:

1. Read all of the config files and determine what the final value
present in each config file is.
2. *Then*, in a second pass, enforce requirements like "can't be
changed except at server start".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company