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 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +