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
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 |