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