On 12/23/16 7:26 PM, Tom Lane wrote:
> David Steele <david@pgmasters.net> writes:
>> What about a ./configure option that basically removes the min/max
>> limits of every setting where it makes sense?
>
> It's pretty much never the case that anything goes; for example,
> are we going to insist that the code be able to respond sanely to
> negative checkpoint_timeout? The GUC limit mechanism was really
> invented to avoid having to do that, as much or more than preventing
> users from picking "bad" values.
Well, this option would only be available if you built Postgres from
source which I doubt most users are doing. I had originally thought it
would be best to enforce some sanity on the values, but then thought it
might be useful to give settings completely bogus values for testing
purposes.
I'd be OK with some sensible limits, but I think that defeats to point
to some extent.
> And I don't want to maintain two sets of limits, so I'm not for
> some sort of "training wheels off" vs "training wheels on" GUC.
I wasn't proposing that this be a GUC. If I gave that impression it's
because I didn't convey my idea accurately.
> We could move towards a project policy that limits be set according
> to what's sensible for the code to support rather than what seems
> like useful ranges. Again though, most of the ensuing work needs to
> be documentation not code changes.
I'm honestly not sure I would want to kick off all the training wheels.
For instance, a poorly considered checkpoint_timeout setting may lead to
terrible performance, but should still leave the user with a consistent
database, and hopefully some wisdom in the bargain.
--
-David
david@pgmasters.net
