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 01:16:10PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > So my larger question is why a single-guc-per-file avoids corruption
> > while having all the gucs in a single file does not.
>
> If it's file-per-GUC, then when two sessions try to write different GUCs,
> there is no conflict. When they try to write the same GUC, the end result
> will be one value or the other (assuming use of atomic rename). Which
> seems fine.
>
> If it's single-file, and we don't lock, then when two sessions try to
> write different GUCs, one's update can be lost altogether, because
> whichever one renames second didn't see the first one's update. That
> doesn't seem acceptable.

Yes, I understand now --- with file-per-GUC, you can say one was later
than the other, but when changing two different GUCs, a single file
implementation doesn't have that logical clarity.

FYI, we will need to use create-rename even without the problem of
creating corrupted files because we need it to avoid backends reading
partially-written files.

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

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