GUCs that need restart

There are quite a few GUC parameters that need restart. Is there a way we
can avoid some of them needing restart? I am specifically looking at
archive_mode and the new wal_level.

From my limited understanding, these parameters need restart because in a
running cluster we cannot safely change these GUCs and make sure that
other/running backends will pick them up immediately so that they start
behaving differently as required by the GUC.

Are there other reasons to have them set to PGC_POSTMASTER?

If the above is correct and the only reason, then can we have them assigned
to a new PGC_ mode and have the SET commands somehow wait for all backends
to pickup the value before returning? (specifically, wait for any running
backends to exit the transaction).

I know there are genuine reasons behind having them depend on restart, but
am just trying to eliminate that, at least for some parameters which a DBA
might want to change on the fly, being fully aware of the consequences.

Regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.enterprisedb.com

singh(dot)gurjeet(at){ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device

Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> wrote:

> There are quite a few GUC parameters that need restart. Is there a
> way we can avoid some of them needing restart? I am specifically
> looking at archive_mode and the new wal_level.

I'll second this on a "don't know if it's practicable, but it would
be nice if..." basis.

-Kevin

On May 4, 2010, at 3:48 PM, Gurjeet Singh wrote:
> There are quite a few GUC parameters that need restart. Is there a way we can avoid some of them needing restart? I am specifically looking at archive_mode and the new wal_level.

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.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

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.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us

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