On 12/23/16 6:12 PM, Michael Paquier wrote: > On Sat, Dec 24, 2016 at 6:02 AM, David Steele <da...@pgmasters.net> wrote: >> On 12/23/16 10:24 AM, Tom Lane wrote: >>> Andres Freund <and...@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-f62fb08d7...@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 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
