On Mon, Aug 5, 2013 at 01:16:10PM -0400, Tom Lane wrote: > Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
