Обсуждение: Re: [HACKERS] Remove lower limit on checkpoint_timeout?
Andres Freund <andres@anarazel.de> writes:
> While it's not a particularly good idea to set it to 1s on a production
> system, I don't see why we need to prevent that. It's not like 30s is
> likely to be a good idea either.
> Hence I'd like to set the lower limit to 1s.
OK, but the documentation for it needs some work if you're going to
do that. It only warns against making the timeout too large, not
too small.
regards, tom lane
On 12/23/16 10:24 AM, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: >> While it's not a particularly good idea to set it to 1s on a production >> system, I don't see why we need to prevent that. It's not like 30s is >> likely to be a good idea either. > >> Hence I'd like to set the lower limit to 1s. > > OK, but the documentation for it needs some work if you're going to > do that. It only warns against making the timeout too large, not > too small. +1 for the lower limit and the docs. -- -David david@pgmasters.net
On Sat, Dec 24, 2016 at 6:02 AM, David Steele <david@pgmasters.net> wrote: > On 12/23/16 10:24 AM, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: >>> While it's not a particularly good idea to set it to 1s on a production >>> system, I don't see why we need to prevent that. It's not like 30s is >>> likely to be a good idea either. >> >>> Hence I'd like to set the lower limit to 1s. >> >> OK, but the documentation for it needs some work if you're going to >> do that. It only warns against making the timeout too large, not >> too small. > > +1 for the lower limit and the docs. I wish we were more loose regarding the limits of some parameters, see for example this recent thread about bgwriter ones: https://www.postgresql.org/message-id/f6e58a22-030b-eb8a-5457-f62fb08d701c@BlueTreble.com So +1 for lowering checkpoint_timeout, lower values are stupid for production systems, but not for developers. -- Michael
On 12/23/16 6:12 PM, Michael Paquier wrote: > On Sat, Dec 24, 2016 at 6:02 AM, David Steele <david@pgmasters.net> wrote: >> On 12/23/16 10:24 AM, Tom Lane wrote: >>> Andres Freund <andres@anarazel.de> writes: >>>> While it's not a particularly good idea to set it to 1s on a production >>>> system, I don't see why we need to prevent that. It's not like 30s is >>>> likely to be a good idea either. >>> >>>> Hence I'd like to set the lower limit to 1s. >>> >>> OK, but the documentation for it needs some work if you're going to >>> do that. It only warns against making the timeout too large, not >>> too small. >> >> +1 for the lower limit and the docs. > > I wish we were more loose regarding the limits of some parameters, see > for example this recent thread about bgwriter ones: > https://www.postgresql.org/message-id/f6e58a22-030b-eb8a-5457-f62fb08d701c@BlueTreble.com > So +1 for lowering checkpoint_timeout, lower values are stupid for > production systems, but not for developers. What about a ./configure option that basically removes the min/max limits of every setting where it makes sense? We can discuss what's good for the user without being inconvenienced ourselves. It's something I'd be willing to write a patch for if there's interest. We can start with a few that have been discussed and work our way out from there. I agree with Andres about lowering the checkpoint_timeout limit in general, but it seems like this would allow us to make development more convenient even when we can't agree on changing limits for production builds. -- -David david@pgmasters.net
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.
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.
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.
regards, tom lane
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