Re: GUCs that need restart

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: GUCs that need restart
Дата
Msg-id AANLkTil5eLB8MTBFYzvurSGgqx5UlApVrtoj8t96V5ZG@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GUCs that need restart  (Greg Smith <greg@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Performance problem in textanycat/anytextcat
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Performance problem in textanycat/anytextcat