On Fri, Jan 28, 2022 at 06:32:27PM +0900, Kyotaro Horiguchi wrote: > End-of-recovery checkpoint is requested as CHECKPOINT_WAIT, which > seems to me to mean the state is always DB_IN_ARCHIVE_RECOVERY while > the checkpoint is running?
With the patch, yes, we would keep the control file under
DB_IN_{ARCHIVE,CRASH}_RECOVERY during the whole period of the
end-of-recovery checkpoint. On HEAD, we would have DB_SHUTDOWNING
until the end-of-recovery checkpoint completes, after which we switch
to DB_SHUTDOWNED for a short time before DB_IN_PRODUCTION.
> If correct, if server is killed druing the
> end-of-recovery checkpoint, the state stays DB_IN_ARCHIVE_RECOVERY
> instead of DB_SHUTDOWNING or DB_SHUTDOWNED. AFAICS there's no
> differece between the first two at next startup.
One difference is the hint given to the user at the follow-up startup.
Crash and archive recovery states can freak people easily as they
mention the risk of corruption. Using DB_SHUTDOWNING reduces this
window.
> I dont' think DB_SHUTDOWNED case is not worth considering here.
Well, this patch also means there is a small window where we have
DB_IN_ARCHIVE_RECOVERY in the control file with the new timeline and
minRecoveryPoint not set, rather than DB_SHUTDOWNED.
--
Michael
signature.asc
Description: PGP signature
