Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@2ndquadrant.com>, Greg Stark <stark@mit.edu>, 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
Date: 2013-08-05T17:56:40Z
Lists: pgsql-hackers 
Josh Berkus <josh@agliodbs.com> writes:
> I'll also point out that some of our settings only really "work" in
> combinations of two or more settings.  For example, one doesn't want to
> set archive_mode = on unless one is setting archive_command as well.
> And generally if one sets sequential_page_cost, one is changing the
> other cost parameters as well.  And logging parameters are generally
> managed as a set.

> So the case of two sessions both modifying ALTER SYSTEM SET, and one
> succeeding for some-but-all-GUCS, and the other succeeding for
> some-but-not-all-GUCs, would not be user-friendly or pretty, even if
> each setting change succeeded or failed atomically.

That is a killer point.  So really the value of the global lock is to
ensure serializability when transactions are updating multiple GUCs.

			regards, tom lane