On 2013-08-05 13:56:40 -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.
I don't think a global lock helps very much WRT this. Likely the lock will be released after a single SET finishes, in that case it doesn't guarantee much for a set of SETs. Even if we were to make it be released only at session end, the session that wants to set something conflicting will only be blocked by wanting to set the lock, it won't be prevented from doing so. The SET will then succeed after the other session finished. I don't think we're designing a feature that's supposed to be used under heavy concurrency here. If you have users/tools doing conflicting actions as superusers you need to solve that by social means, not by technical ones. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers