On Mon, Aug 5, 2013 at 05:29:48PM -0400, Bruce Momjian wrote: > > 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.
To clarify, I talked about new backends above, but on Unix and Windows, new backends inherit the postmaster GUC settings, so it would only be config file reload that would possibly see the single-guc-per-file in an inconsistent state. And we already have this possibility if someone edits postgresql.conf, and while the editor is writing the file, a backend is reading the file via a reload. Now, I assume that ALTER SYSTEM SET would automatically issue a pg_reload_conf(), so we would need to make sure that people modifying multiple parameters that are related do it in a single transaction, and that we issue a pg_reload_conf() only after all values have been changed. -- 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
