On Mon, Aug 5, 2013 at 01:16:10PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.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@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
