GUCs that need restart

Поиск
Список
Период
Сортировка
Искать
От
Gurjeet Singh
Тема
GUCs that need restart
Дата
в 17:54:49
Msg-id
k2u65937bea1005041348wb11a2b23rb4b23572a86a13d0@mail.gmail.com
Список
Дерево обсуждения
GUCs that need restart Gurjeet Singh <singh.gurjeet@gmail.com>
Re: GUCs that need restart Jim Nasby <decibel@decibel.org>
Re: GUCs that need restart Greg Smith <greg@2ndquadrant.com>
Re: GUCs that need restart Robert Haas <robertmhaas@gmail.com>
Re: GUCs that need restart "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
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.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device
В списке pgsql-hackers по дате отправления
От: Simon Riggs
Дата:
От: Josh Berkus
Дата:
FAQ