Re: Raising the checkpoint_timeout limit - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Raising the checkpoint_timeout limit
Date
Msg-id CANP8+j+1761gQsR2w5bp67gXv1jY5=fW3H5OitVoEWLRnhMb=Q@mail.gmail.com
Whole thread Raw
In response to Re: Raising the checkpoint_timeout limit  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Raising the checkpoint_timeout limit
List pgsql-hackers
On 2 February 2016 at 05:54, Michael Paquier <michael.paquier@gmail.com> wrote:
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

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: get current log file
Next
From: José Luis Tallón
Date:
Subject: Re: PostgreSQL Auditing