On Fri, Dec 27, 2013 at 5:01 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Dec 24, 2013 at 10:08 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> When I read ProcessConfigFile() more carefully, I found another related
>> problem. The procedure to reproduce the problem is here.
>>
>> --------------------
>> $ psql
>> =# ALTER SYSTEM SET shared_buffers = '256MB';
>> =# \q
>>
>> $ echo "shared_buffers = '256MB'" >> $PGDATA/postgresql.conf
>> $ pg_ctl -D $PGDATA reload
>> 2013-12-25 03:05:44 JST LOG: parameter "shared_buffers" cannot be
>> changed without restarting the server
>> 2013-12-25 03:05:44 JST LOG: parameter "shared_buffers" cannot be
>> changed without restarting the server
>> 2013-12-25 03:05:44 JST LOG: configuration file
>> "/dav/alter-system/data/postgresql.auto.conf" contains errors;
>> unaffected changes were applied
>> --------------------
>>
>> Both postgresql.conf and postgresql.auto.conf contain the setting of
>> the parameter that cannot be changed without restarting the server.
>> But only postgresql.auto.conf was logged, and which would be confusing,
>> I'm afraid. I think that this problem should be fixed together with the
>> problem that I reported before. Thought?
>
> I have run into this problem on many occasions because my benchmark
> scripts usually append a hunk of stuff to postgresql.conf, and any
> parameters that were already set generate this warning every time you
> reload, because postgresql.conf now mentions that parameter twice.
> I'm not quite sure what other problem you want to fix it together
> with,
The 2 problems are:
1. First is that if user changes the config parameter (for ex.
shared_buffers) both by manually editing postgresql.conf and by using Alter System command and then
reload the config, it will show the message for parameter 'shared_buffers' twice, but
will only show the last file where it exists. The detailed description of problem is in current mail.
2. The other problem is in some cases the name of file it display is
junk, problem and fix can be found at link:
http://www.postgresql.org/message-id/CAA4eK1+-yD2p=+6tdj_xPruHN4m_CkvFr51aH0gv3SXLGOACGg@mail.gmail.com
>and I'm not sure what the right fix is either, but +1 for coming
> up with some solution that's better than what we have now.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com