| From: | Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> | 
|---|---|
| To: | PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | GUCs that need restart | 
| Date: | 2010-05-04 20:48:12 | 
| Message-ID: | k2u65937bea1005041348wb11a2b23rb4b23572a86a13d0@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2010-05-04 20:57:38 | Re: max_standby_delay considered harmful | 
| Previous Message | Simon Riggs | 2010-05-04 20:48:07 | Re: testing HS/SR - 1 vs 2 performance |