Re: Raising the checkpoint_timeout limit

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Noah Misch <noah(at)leadboat(dot)com>, 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 04:10:39
Message-ID: CA+TgmobTBBeRF03MF31GNS636eTv4fC4umUU-g57OBE94su5yg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 2, 2016 at 10:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

If smart people[1] want to set checkpoint_timeout to a value higher
than 1 day[2], then I think we should let them.

I think what will happen if you set checkpoint_timeout to 1 year is
that you will checkpoint solely based on WAL volume, which does not
seem like a manifestly unreasonable thing to want. It's true that if
you set BOTH max_wal_size AND checkpoint_timeout to $WAYTOOBIG then
something bad might happen to you, but even such configurations are
actually not totally crazy: for example, you could ingest data into a
temporary PostgreSQL instance and then do logical replication from
there to another cluster for permanent storage. You don't really need
recovery or shutdown to happen in the lifetime of the cluster, so no
harm, no foul. Now, you could also set such configuration settings in
a situation where it will not work out well. But that is true of most
configuration settings.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

[1] like Andres
[2] see original post

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-02-03 05:42:36 Re: WAL Re-Writes
Previous Message Robert Haas 2016-02-03 04:02:20 Re: [PROPOSAL] Client Log Output Filtering