Re: 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 12:53:24PM -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2013-08-05 12:18:25 -0400, Bruce Momjian wrote:
> >> I am unclear why we don't need a lock around _each_ GUC, i.e. if two
> >> sessions try to modify the same GUC at the same time. And if we need a
> >> lock, seems we can have just one and write all the settings to one file
> >> --- it is not like we have trouble doing locking, though this is
> >> cluster-wide locking.
>
> > If you have two sessions modifying the same variable, one is going to
> > win and overwrite the other's setting with or without locking around
> > GUCs unless you error out if somebody else holds the lock.
>
> The point of a lock is just to ensure that the end result is one valid
> state or the other, and not something corrupt. We would certainly need a
> lock if we write to a single file. With file-per-GUC, we could possibly
> dispense with a lock if we depend on atomic file rename(); though whether
> it's wise to assume that for Windows is unclear. (Note that we ought to
> write a temp file and rename it into place anyway, to avoid possibly
> corrupting the existing file on out-of-disk-space. The only thing that
> needs discussion is whether to add an explicit lock around that.)

So my larger question is why a single-guc-per-file avoids corruption
while having all the gucs in a single file does not. It seems the later
reduces the probability of lost updates, but does not eliminate it.

Also, should I be concerned that everyone removed my pg_upgrade question
in their replies. :-O

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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