Re: 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 10:52:52AM -0700, David Johnston wrote:
> Josh Berkus wrote
> > (this discussion concerns issue (D), file-per-setting vs. one-big-file)
> > 
> > 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.
> 
> Can the final file write occur only at "COMMIT;" with anything inside a
> transaction simply staged up for later saving (or rollback).  The file write
> phase as a whole then needs to be atomic and not just a single GUC-file.

Yes, the writes would only happen at commit, but I see of no way to have
the renames happen atomically.

> Could the system read the last update timestamp of each GUC-file when the
> original statement is executed and then re-read all of them at commit and
> fail with some kind of serialization error if the last-update timestamp on
> any of the files has changed?

That sounds like a mess --- clearly a global lock and a single file for
all GUCs would be perferrable.

> I dislike the idea of any kind of automatic reload.  That said some kind of
> "have their been any configuration changes since last reload?"
> query/function makes sense.  In can be plugged into Nagios or similar to
> warn if these changes are occurring but made live.

Who talked about automatic reload?  The bigger problem is new backends
starting and seeing partial state during the renames.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +