On Sat, Jan 29, 2022 at 7:43 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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.
If the server crashes in end-of-recovery, in the follow-up startup,
the server has to start all the recovery right? In that case,
DB_IN_{ARCHIVE, CRASH}_RECOVERY would represent the correct state to
the user, not the DB_SHUTDOWNING/DB_SHUTDOWNED IMO.
There's another option to have a new state
DB_IN_END_OF_RECOVERY_CHECKPOINT, if the DB_IN_{ARCHIVE,
CRASH}_RECOVERY really scares users of end-of-recovery crash?
Regards,
Bharath Rupireddy.
