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])

On Mon, Aug  5, 2013 at 01:56:40PM -0400, Tom Lane wrote:
> 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.

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  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +