Re: A few new options for CHECKPOINT

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
Cc: "'Bossart, Nathan'" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A few new options for CHECKPOINT
Date: 2020-11-25 04:47:46
Message-ID: X73h8ppliRgD6CDU@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 25, 2020 at 01:07:47AM +0000, tsunakawa(dot)takay(at)fujitsu(dot)com wrote:
> From: Bossart, Nathan <bossartn(at)amazon(dot)com>
>> 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.
>>
>> [0] https://www.postgresql.org/docs/devel/backup-file.html
>
> Ah, understood. I agree that the slow or spread manual checkpoint is good to have.

I can see the use case for IMMEDIATE, but I fail to see the use cases
for WAIT and FORCE. CHECKPOINT_FORCE is internally implied for the
end-of-recovery and shutdown checkpoints. WAIT could be a dangerous
thing if disabled, as clients could pile up requests to the
checkpointer for no real purpose.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-11-25 05:00:06 Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)
Previous Message Peter Geoghegan 2020-11-25 04:35:13 Re: Deleting older versions in unique indexes to avoid page splits