Re: GUCs that need restart

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Jim Nasby <decibel(at)decibel(dot)org>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GUCs that need restart
Date: 2010-05-18 01:21:41
Message-ID: AANLkTil5eLB8MTBFYzvurSGgqx5UlApVrtoj8t96V5ZG@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 17, 2010 at 5:20 PM, Greg Smith <greg(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-05-18 01:23:30 Re: Performance problem in textanycat/anytextcat
Previous Message Robert Haas 2010-05-18 01:09:29 Re: Performance problem in textanycat/anytextcat