On Tuesday, July 23, 2013 5:06 AM Josh Berkus wrote: > All, > > Christophe just discovered something with include files which is going > to cause issues with ALTER SYSTEM SET. > > So, take as a hypothetical that you use the default postgresql.conf > file, which sets shared_buffers = 32MB. > > Instead of editing this file, you do ALTER SYSTEM SET shared_buffers = > '1GB', which updates config/postgresql.auto.conf. > > Then you restart PostgreSQL. > > Everything is hunky-dory, until a later occasion where you *reload* > postgresql. Then postgres startup hits the first "shared_buffers=32MB" > (in postgresql.conf), says "I can't change shared buffers on a reload", > and aborts before ever getting to postgresql.auto.conf.
It doesn't abort after showing initial message "parameter %s cannot be changed without restart", rather it processes all remaining parameters. We can even test it by setting 1 postmaster and 1 sighup variable, after reload, even though it log message for postmaster variable, but it will set the sighup variable. So in this the real problem is that there is some message in log which can create confusion, otherwise the behavior will be exactly what user wants as per Postgres specs. To avoid the message, following can be done: 1. We need to make sure that in function ProcessConfigFile before calling set_config_option(), list of parameters is unique. a. it can be done while storing the elements in list as suggested by me in my yesterday's mail. http://www.postgresql.org/message-id/004c01ce8761$b8a4ab20$29ee0160$@kap...@huawei.com b. after parsing all the config files, make sure the list contain one entry for any variable (giving priority to elements that come later) 2. As this is just a confusing message issue, we can even update the docs to explain this behavior. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers