On Mon, Aug 5, 2013 at 10:21:56AM -0700, Josh Berkus wrote: > (this discussion concerns issue (D), file-per-setting vs. one-big-file) > > On 08/05/2013 10:16 AM, Tom Lane wrote: > > Bruce Momjian <br...@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.
Wow, that is a good point. I just mentioned in a previous email that sessions are going to be created while this is going on and they can't see partially-written files, so we need the create/rename dance. One new twist is that certain settings have to be _all_ set, or the backend is going to throw an error. > 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. Remember the backends starting up during this too. A global lock is looking unavoidable. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers