On Tuesday, August 06, 2013 5:39 PM Bruce Momjian wrote: > 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.
Can't we leave this onus of conflict of changing dependent parameters on user, such that he should do it carefully? Other databases SQL Server, Oracle also has similar feature, so there user's also must be handling by themselves. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
