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