Re: A few new options for CHECKPOINT
От | Fujii Masao |
---|---|
Тема | Re: A few new options for CHECKPOINT |
Дата | |
Msg-id | b1d83ae4-5cb3-ce6c-7f86-1048ab88593f@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: A few new options for CHECKPOINT (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
On 2020/11/25 13:47, Michael Paquier wrote: > On Wed, Nov 25, 2020 at 01:07:47AM +0000, tsunakawa.takay@fujitsu.com wrote: >> From: Bossart, Nathan <bossartn@amazon.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. We may want to disable WAIT (or specify wait timeout?) when doing checkpoint with IMMEDIATE disabled, to avoid long-running command. OTOH, if we support WAIT disabled, I'd like to have the feature to see whether the checkpoint has been completed or not. We can do that by using log_checkpoints, but that's not convenient. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: