(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
