Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date
Msg-id 29475.1375722970@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Bruce Momjian <bruce@momjian.us>)
Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: mvcc catalo gsnapshots and TopTransactionContext
Next
From: "David E. Wheeler"
Date:
Subject: Re: Comma Comma Comma 8601