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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Greg Stark <stark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date: 2013-08-05 16:46:11
Message-ID: 20130805164611.GD19850@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-08-05 12:18:25 -0400, Bruce Momjian wrote:
> 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(at)2ndquadrant(dot)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.

If you have two sessions modifying the same variable, one is going to
win and overwrite the other's setting with or without locking around
GUCs unless you error out if somebody else holds the lock.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2013-08-05 16:52:22 Re: StrategyGetBuffer optimization, take 2
Previous Message Bruce Momjian 2013-08-05 16:42:26 Re: CREATE EVENT TRIGGER syntax