On Tue, Feb 2, 2016 at 1:16 PM, Noah Misch <noah@leadboat.com> wrote: > On Tue, Feb 02, 2016 at 01:13:20AM +0100, Andres Freund wrote: >> is there any reason for the rather arbitrary and low checkpoint_timeout >> limit? > > Not that I know, and it is inconvenient. > >> I'm not sure what'd actually be a good upper limit. I'd be inclined to >> even go to as high as a week or so. A lot of our settings have >> upper/lower limits that aren't a good idea in general. > > In general, I favor having limits reflect fundamental system limitations > rather than paternalism. Therefore, I would allow INT_MAX (68 years).
+1. This way users can play as they wish.
If people wish to turn off crash recovery, they can already set fsync=off. I don't wish to see us support a setting that causes problems for people that don't understand what checkpoints are and why everybody needs them.
The current code needs to act differently with regard to very low settings, so when we are a small number of blocks remaining we don't spend hours performing them. Allowing very large values would make that even more strange.
I would put a limit of 100,000 seconds = 27 hours.
Some systems offer a recovery_time_objective setting that is used to control how frequently checkpoints occur. That might be a more usable approach.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services