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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
