Re: File-per-GUC WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

(this discussion concerns issue (D), file-per-setting vs. one-big-file)

On 08/05/2013 10:16 AM, 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.

I'll also point out that some of our settings only really "work" in
combinations of two or more settings.  For example, one doesn't want to
set archive_mode = on unless one is setting archive_command as well.
And generally if one sets sequential_page_cost, one is changing the
other cost parameters as well.  And logging parameters are generally
managed as a set.

So the case of two sessions both modifying ALTER SYSTEM SET, and one
succeeding for some-but-all-GUCS, and the other succeeding for
some-but-not-all-GUCs, would not be user-friendly or pretty, even if
each setting change succeeded or failed atomically.

Also, one of the reasons Amit went to one-big-file was the question of:
if each setting is changed independantly, how do we know when to send
the backend a reload()?  IIRC, anyway.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com