On Thu, Aug 1, 2013 at 03:40:22PM +0100, Greg Stark wrote: > Why isn't it enough to just dump out all variables with a source of alter > system to a text file? You can either have a single global lock around that > operation or write it to a new file and move it into place. > > -- > greg > > On 1 Aug 2013 15:19, "Andres Freund" <and...@2ndquadrant.com> wrote: > > On 2013-08-01 15:17:04 +0100, Greg Stark wrote: > > We don't need per guc locking. This is the whole objection Tom had about > > this patch being more complex than it has to be. > > IIRC he objected to using locking *at all* because a simple > one-file-per-setting approach should be used.
I am unclear why we don't need a lock around _each_ GUC, i.e. if two sessions try to modify the same GUC at the same time. And if we need a lock, seems we can have just one and write all the settings to one file --- it is not like we have trouble doing locking, though this is cluster-wide locking. How would users handle renamed GUC variables, as we have done in the past? Would pg_dumpall dump the settings out? Would unrecognized settings throw an error, causing pg_upgrade to fail? -- 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
