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