From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Raising the checkpoint_timeout limit |
Date: | 2016-02-03 03:31:15 |
Message-ID: | CA+Tgmob9COCKqEuEUF8qq+_4QnLpA-ht7TztpBXyDsf5RpNcJA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 2, 2016 at 8:09 PM, Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2016-02-03 03:41:04 | Re: Minor code improvements to create_foreignscan_plan/ExecInitForeignScan |
Previous Message | Robert Haas | 2016-02-03 03:29:44 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |