On Sat, Jan 29, 2022 at 08:07:23PM +0530, Bharath Rupireddy wrote:
> 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?
Well, an end-of-recovery checkpoint is a shutdown checkpoint, and it
relies on the same assumptions in terms of checkpoint logic for the
last 10 years or so, so the state of the control file is not wrong
per-se, either. There are other cases that we may want to worry
about with this change, like the fact that unlogged relation reset
relies on the cluster to be cleanly shut down when we begin entering
the replay loop. And it seems to me that this has not been looked
at. A second thing would be the introduction of an invalid LSN
minimum recovery point in the control file while in
DB_IN_ARCHIVE_RECOVERY when we are done with the checkpoint, joining
my point of upthread.
At the end of the day, it may be better to just let this stuff be.
Another argument for doing nothing is that this could cause
hard-to-spot conflicts when it comes to back-patch something.
--
Michael
