Re: A few new options for CHECKPOINT

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A few new options for CHECKPOINT
Date: 2020-11-25 00:48:26
Message-ID: 95792933-8418-41F3-A2FA-327A0E4F45B1@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/24/20, 4:03 PM, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote:
> From: Bossart, Nathan <bossartn(at)amazon(dot)com>
>> The main purpose of this patch is to give users more control over their manually
>> requested checkpoints or restartpoints. I suspect the most useful option is
>> IMMEDIATE, which can help avoid checkpoint- related IO spikes. However, I
>> didn't see any strong reason to prevent users from also adjusting FORCE and
>> WAIT.
>
> I think just IMMEDIATE would suffice, too. But could you tell us why you got to want to give users more control? Could we know concrete example situations where users want to perform CHECKPOINT with options?

It may be useful for backups taken with the "consistent snapshot"
approach. As noted in the documentation [0], running CHECKPOINT
before taking the snapshot can reduce recovery time. However, users
might wish to avoid the IO spike caused by an immediate checkpoint.

Nathan

[0] https://www.postgresql.org/docs/devel/backup-file.html

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-11-25 01:07:14 Re: Libpq support to connect to standby server as priority
Previous Message tsunakawa.takay@fujitsu.com 2020-11-25 00:27:20 RE: [PoC] Non-volatile WAL buffer