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. 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? 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. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Proposal-for-Allow-postgresql-conf-values-to-be-changed-via-SQL-tp5729917p5766338.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
