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
signature.asc
Description: PGP signature
