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 <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.
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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
