Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Craig Ringer <craig@2ndquadrant.com>
From: Craig Ringer <craig@2ndquadrant.com>
To: Greg Stark <stark@mit.edu>
Cc: Greg Smith <greg@2ndquadrant.com>, Amit Kapila <amit.kapila@huawei.com>, Andres Freund <andres@2ndquadrant.com>, Boszormenyi Zoltan <zb@cybertec.at>, pgsql-hackers@postgresql.org
Date: 2013-03-13T06:42:18Z
Lists: pgsql-hackers
On 03/12/2013 06:27 AM, Craig Ringer wrote: >> > Think also about the case where someone wants to change multiple >> > values together and having just some set and not others would be >> > inconsistent. > Yeah, that's a killer. The reload would need to be scheduled for COMMIT > time, it can't be done by `SET PERSISTENT` directly. Thinking about this some more, I'm not sure this is a good idea. Right now, SET takes effect immediately. Always, without exception. Delaying SET PERSISTENT's effects until commit would make it inconsistent with SET's normal behaviour. However, *not* delaying it would make it another quirky not-transactional not-atomic command. That's OK, but if it's not going to follow transactional semantics it should not be allowed to run within a transaction, like VACUUM . Writing the changes immediately but deferring the reload until commit seems to be the worst of those two worlds. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services