From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Raising the checkpoint_timeout limit |
Date: | 2016-02-03 03:58:15 |
Message-ID: | 32558.1454471895@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> On Tue, Feb 02, 2016 at 12:24:50PM +0100, Andres Freund wrote:
>> On 2016-02-01 23:16:16 -0500, Noah Misch wrote:
>>> 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.
I've gotta go with the "paternalism" side of the argument here. Suppose
you configure your system to checkpoint once a year --- what is going to
happen when the year is up? Or when you try to shut it down? You *will*
regret such a setting.
I don't think we should allow the checkpoint distances to be so large that
checkpoints don't happen in the normal course of events. I'd be okay with
the max being a day, perhaps.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-02-03 04:02:20 | Re: [PROPOSAL] Client Log Output Filtering |
Previous Message | Kyotaro HORIGUCHI | 2016-02-03 03:51:19 | Incorrect formula for SysV IPC parameters |