| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
| Date: | 2013-03-13 06:42:18 |
| Message-ID: | 51401FCA.7090502@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2013-03-13 06:44:14 | Re: Statistics and selectivity estimation for ranges |
| Previous Message | Jeff Davis | 2013-03-13 06:33:04 | Re: Enabling Checksums |