Horton

Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

Bruce Momjian <bruce@momjian.us>

View thread View on postgr.es
From: Bruce Momjian <bruce@momjian.us>
To: Greg Stark <stark@mit.edu>
Cc: Andres Freund <andres@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Fujii Masao <masao.fujii@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Amit Kapila <amit.kapila@huawei.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, pgsql-hackers@postgresql.org, Josh Berkus <josh@agliodbs.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2013-08-05T16:18:25Z
Lists: pgsql-hackers 
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. +