Horton

Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

Greg Stark <stark@mit.edu>

View thread View on postgr.es
From: Greg Stark <stark@mit.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Fujii Masao <masao.fujii@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Amit Kapila <amit.kapila@huawei.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, pgsql-hackers@postgresql.org, Josh Berkus <josh@agliodbs.com>
Date: 2013-08-05T23:17:14Z
Lists: pgsql-hackers 
On Mon, Aug 5, 2013 at 6:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If it's file-per-GUC, then when two sessions try to write different GUCs,
> there is no conflict

Well it's not that there's no conflict. It's just that we don't detect
the conflict. If you raise shared_buffers and I calculate the optimal
work_mem based on the old shared_buffers and set work_mem I may well
set it too large. Or if I set multiple settings together and you set
one of them you'll undo my change and lose just part of my changes but
not stop me from setting the others inconsistently.

I think it's actually better to lose a whole set of changes than to
intermix two sets of changes in unpredictable ways.  And I would
suggest instead of doing a rename we just create a second link leaving
behind the original link as well. That means you wouldn't be losing
the other changes entirely you would have the history of the settings
as they were briefly at least.



-- 
greg