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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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>
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 17:08:12
Message-ID: 20130805170812.GA2391@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-08-05 12:53:24 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2013-08-05 12:18:25 -0400, Bruce Momjian wrote:
> >> 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.
>
> The point of a lock is just to ensure that the end result is one valid
> state or the other, and not something corrupt.

Sure. That's what I tried to explain. I've completely missed to mention
in this mail why the safe rename dance is sufficient to guarantee a
correct file with one-file-per-guc...

> We would certainly need a
> lock if we write to a single file. With file-per-GUC, we could possibly
> dispense with a lock if we depend on atomic file rename(); though whether
> it's wise to assume that for Windows is unclear.

Afaik it should be safe on anything NT based via Replacefile. Anything
else/earlier isn't supported anyways... I think there's already a custom
rename() implementation on windows?
Don't we already rely on atomic renames working for the control file?

> (Note that we ought to
> write a temp file and rename it into place anyway, to avoid possibly
> corrupting the existing file on out-of-disk-space. The only thing that
> needs discussion is whether to add an explicit lock around that.)

Yes, agreed. All versions of the patch that I've read have done so luckily.

Greetings,

Andres Freund

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2013-08-05 17:09:31 Re: mvcc catalo gsnapshots and TopTransactionContext
Previous Message Bruce Momjian 2013-08-05 17:05:03 Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])