Greetings, * Bossart, Nathan (bossa...@amazon.com) wrote: > On 11/24/20, 4:03 PM, "tsunakawa.ta...@fujitsu.com" > <tsunakawa.ta...@fujitsu.com> wrote: > > From: Bossart, Nathan <bossa...@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? 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.
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
signature.asc
Description: PGP signature
