Tom, Florian,
>> On the downside, the current behaviour prevents problems if someone changes
>> two interrelated GUCs, but makes a mistake at one of them. For example,
>> someone might drastically lower bgwriter_delay but might botch the matching
>> adjustment of bgwriter_lru_maxpages.
>
> That's a fair point, but the current behavior only saves you if the
> botch is such that the new value is detectably invalid, as opposed to
> say just a factor of 100 off from what you meant. Not sure that that's
> all that helpful.
Hmmm. As someone who often deploys pg.conf changes as part of a
production code rollout, I actually like the "atomic" nature of updating
postgresql.conf -- that is, all your changes succeed, or they all fail.
If we add this feature, I'd want there to be an option which allows
getting the current all-or-none behavior.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
