Re: postgresql.auto.conf and reload - Mailing list pgsql-hackers

From Robert Haas
Subject Re: postgresql.auto.conf and reload
Date
Msg-id CA+TgmoY0uZhxiM0kdF9syxRAHf39n8e0zj4ACzZ9te4FWm7D_g@mail.gmail.com
Whole thread Raw
In response to Re: postgresql.auto.conf and reload  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Jul 5, 2014 at 10:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.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



pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: Securing "make check" (CVE-2014-0067)
Next
From: Josh Berkus
Date:
Subject: Re: postgresql.auto.conf and reload