Re: GUCs that need restart - Mailing list pgsql-hackers

From Robert Haas
Subject Re: GUCs that need restart
Date
Msg-id AANLkTil5eLB8MTBFYzvurSGgqx5UlApVrtoj8t96V5ZG@mail.gmail.com
Whole thread Raw
In response to Re: GUCs that need restart  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
On Mon, May 17, 2010 at 5:20 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Jim Nasby wrote:
>>
>> For archive_mode you should check the archives; where was discussion on
>> exactly why we can only enable archiving on restart. That GUC was added
>> specifically so that archive_command didn't require a restart
>
> I linked the most relevant bits from the archives into
> http://wiki.postgresql.org/wiki/ClusterFeatures#Start.2Fstop_archiving_at_runtime
>
> This item was pretty high up on the last round of hacker polling at the
> clustering meeting that list came out of.  But since it's strictly
> convenient rather than a new feature, it's hard to justify working on, given
> the fixed pool of people who feel comfortable working on this code.

The new setting for wal_level changes the picture here somewhat, too.
I think to decrease wal_level you would need to:

(1) Write an XLOG_PARAMETER_CHANGE record with the new value.
(2) Somehow notify all the backends that they should start using the
new value (note that it will cause a correctness issue if they start
using it before the XLOG_PARAMETER_CHANGE record is written).

To increase wal_level you would need to:

(1) Somehow notify all the backends that they should start using the new value.
(2) Somehow verify that all backends have in fact picked up the new value.
(3) Write an XLOG_PARAMETER_CHANGE record with the new value.

You'd have to make sure to handle all the corner cases, too, like what
happens if the value gets (in/de)creased and then changed again before
the first value has fully propagated...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Performance problem in textanycat/anytextcat
Next
From: Tom Lane
Date:
Subject: Re: Performance problem in textanycat/anytextcat