On Mon, Aug 5, 2013 at 01:56:40PM -0400, Tom Lane wrote: > Josh Berkus <j...@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.
Well, I think it is more than that. The global lock will allow multiple GUCs to be modified in a serializable fashion, but unless you have new backends wait until that lock is clear, new backends are going to see the directory in an inconsistent state if we keep a single-guc-per-file. So, unless we want new backends to hang during ALTER SYSTEM SET operations, I think we are going to need a global lock and all gucs in a single file. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
