On 12/23/16 7:26 PM, Tom Lane wrote: > David Steele <da...@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 da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers