On Mon, Aug 5, 2013 at 10:52:52AM -0700, David Johnston wrote: > Josh Berkus wrote > > (this discussion concerns issue (D), file-per-setting vs. one-big-file) > > > > 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. > > Can the final file write occur only at "COMMIT;" with anything inside a > transaction simply staged up for later saving (or rollback). The file write > phase as a whole then needs to be atomic and not just a single GUC-file.
Yes, the writes would only happen at commit, but I see of no way to have the renames happen atomically. > Could the system read the last update timestamp of each GUC-file when the > original statement is executed and then re-read all of them at commit and > fail with some kind of serialization error if the last-update timestamp on > any of the files has changed? That sounds like a mess --- clearly a global lock and a single file for all GUCs would be perferrable. > I dislike the idea of any kind of automatic reload. That said some kind of > "have their been any configuration changes since last reload?" > query/function makes sense. In can be plugged into Nagios or similar to > warn if these changes are occurring but made live. Who talked about automatic reload? The bigger problem is new backends starting and seeing partial state during the renames. -- 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
