| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | 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, Josh Berkus <josh(at)agliodbs(dot)com> |
| 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: | 2013-08-05 17:16:10 |
| Message-ID: | 29475.1375722970@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2013-08-05 17:17:59 | Re: Comma Comma Comma 8601 |
| Previous Message | Noah Misch | 2013-08-05 17:09:31 | Re: mvcc catalo gsnapshots and TopTransactionContext |