Re: [HACKERS] Remove lower limit on checkpoint_timeout?
On 12/23/16 7:26 PM, Tom Lane wrote: > David Steele 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
Re: [HACKERS] Remove lower limit on checkpoint_timeout?
David Steele 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remove lower limit on checkpoint_timeout?
On 12/23/16 6:12 PM, Michael Paquier wrote: > On Sat, Dec 24, 2016 at 6:02 AM, David Steele wrote: >> On 12/23/16 10:24 AM, Tom Lane wrote: >>> Andres Freund 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
Re: [HACKERS] Remove lower limit on checkpoint_timeout?
On Sat, Dec 24, 2016 at 6:02 AM, David Steele wrote: > On 12/23/16 10:24 AM, Tom Lane wrote: >> Andres Freund 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. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remove lower limit on checkpoint_timeout?
On 12/23/16 10:24 AM, Tom Lane wrote: > Andres Freund 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 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
Re: [HACKERS] Remove lower limit on checkpoint_timeout?
Andres Freund 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remove lower limit on checkpoint_timeout?
Hello Andres, for testing - like yesterday's 6ef2eba3f - it's annoying that checkpoint_timeout has 30s minimum. I've now locally patched that to be 1s a significant number of times. 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. My 0.02€: I have also resorted to reduce this limit in order to reduce latency and avoid postgres freezing on checkpoints, before checkpoint buffers where sorted. I think I may have tried down to 0.1s which involved some changes, and it worked quite well for the purpose. So basically I would also be in favor to reduce the lower limit down to 1 second, maybe with a warning output when set to low values, say under 1 minute, as you propose. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Remove lower limit on checkpoint_timeout?
Hi, for testing - like yesterday's 6ef2eba3f - it's annoying that checkpoint_timeout has 30s minimum. I've now locally patched that to be 1s a significant number of times. 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. Comments? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers