On Tue, Feb 2, 2016 at 8:09 PM, Noah Misch <n...@leadboat.com> wrote: > On Tue, Feb 02, 2016 at 12:24:50PM +0100, Andres Freund wrote: >> On 2016-02-01 23:16:16 -0500, Noah Misch wrote: >> > On Tue, Feb 02, 2016 at 01:13:20AM +0100, Andres Freund wrote: >> > > 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). >> >> I generally incree with that attitude - I'm disinclined to go just that >> high though. Going close to INT_MAX means having to care about overflow >> in trivial computations, in a scenario we're unlikely to ever >> test. Sure, we can use a debugger to adjust time or accellerate time >> progress, but that's all unrealistic if we're honest. So maybe go with >> a year? > > Okay.
Sounds good to me, too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
