From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org |
Subject: | 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]) |
Date: | 2013-08-05 17:21:56 |
Message-ID: | 51FFDF34.1000704@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(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(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Atri Sharma | 2013-08-05 17:24:41 | Re: query_planner() API change |
Previous Message | David E. Wheeler | 2013-08-05 17:17:59 | Re: Comma Comma Comma 8601 |