Обсуждение: GUCs that need restart
<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>
Gurjeet Singh <singh.gurjeet@gmail.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 amspecifically 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@nasby.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@2ndQuadrant.com www.2ndQuadrant.us
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