On Sat, Jul 5, 2014 at 10:52 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers