GUCs that need restart

Поиск
Список
Период
Сортировка
От Gurjeet Singh
Тема GUCs that need restart
Дата
Msg-id k2u65937bea1005041348wb11a2b23rb4b23572a86a13d0@mail.gmail.com
обсуждение исходный текст
Ответы Re: GUCs that need restart  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: GUCs that need restart  (Jim Nasby <decibel@decibel.org>)
Список pgsql-hackers
<div dir="ltr"><span>There are quite a few GUC parameters that need restart. Is there a way we can avoid some of them
needingrestart? I am specifically looking at archive_mode and the new wal_level. <br /><br />From my limited
understanding,these parameters need restart because in a running cluster we cannot safely change these GUCs and make
surethat other/running backends will pick them up immediately so that they start behaving differently as required by
theGUC</span>.<br /><br />Are there other reasons to have them set to PGC_POSTMASTER?<br /><br />If the above is
correctand the only reason, then can we have them assigned to a new PGC_ mode and have the SET commands somehow wait
forall backends to pickup the value before returning? (specifically, wait for any running backends to exit the
transaction).<br/><br />I know there are genuine reasons behind having them depend on restart, but am just trying to
eliminatethat, at least for some parameters which a DBA might want to change on the fly, being fully aware of the
consequences.<br/><br />Regards,<br />-- <br />gurjeet.singh<br />@ EnterpriseDB - The Enterprise Postgres Company<br
/><ahref="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br /><br />singh.gurjeet@{ gmail | yahoo
}.com<br/>Twitter/Skype: singh_gurjeet<br /><br />Mail sent from my BlackLaptop device<br /></div> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: testing HS/SR - 1 vs 2 performance
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: max_standby_delay considered harmful