Greetings,
* Bossart, Nathan (bossartn@amazon.com) wrote:
> On 11/24/20, 4:03 PM, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com> wrote:
> > From: Bossart, Nathan <bossartn@amazon.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?
Couldwe 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.
I'm a bit confused by the idea here.. The whole point of running a
CHECKPOINT is to get the immediate behavior with the IO spike to get
things flushed out to disk so that, on crash recovery, there's less
outstanding WAL to replay.
Avoiding the IO spike implies that you're waiting for a regular
checkpoint and that additional WAL is building up since that started and
therefore you're going to have to replay that WAL during crash recovery
and so you won't end up reducing your recovery time, so I'm failing to
see the point..? I don't think you really get to have both.. pay the
price at backup time, or pay it during crash recovery.
Thanks,
Stephen
