On Wed, Dec 8, 2021 at 9:49 AM Bossart, Nathan <bossa...@amazon.com> wrote: > > On 12/7/21, 5:21 PM, "Bharath Rupireddy" > <bharath.rupireddyforpostg...@gmail.com> wrote: > > On Wed, Dec 8, 2021 at 2:50 AM Bossart, Nathan <bossa...@amazon.com> wrote: > >> I noticed that some (but not all) of the surrounding messages say > >> "last known up at" the control file time. I'm curious why you chose > >> not to use that phrasing in this case. > > > > If state is DB_IN_END_OF_RECOVERY_CHECKPOINT that means the db was > > interrupted while in end-of-recovery checkpoint, so I used the > > phrasing similar to DB_IN_CRASH_RECOVERY and DB_IN_ARCHIVE_RECOVERY > > cases. I would like to keep it as-is (in the v1 patch) unless anyone > > has other thoughts here? > > (errmsg("database system was interrupted while in recovery at %s", > > (errmsg("database system was interrupted while in recovery at log time %s", > > I think that's alright. The only other small suggestion I have would > be to say "during end-of-recovery checkpoint" instead of "while in > end-of-recovery checkpoint."
"while in" is being used by DB_IN_CRASH_RECOVERY and DB_IN_ARCHIVE_RECOVERY messages. I don't think it's a good idea to deviate from that and use "during". > Another option we might want to consider is to just skip updating the > state entirely for end-of-recovery checkpoints. The state would > instead go straight from DB_IN_CRASH_RECOVERY to DB_IN_PRODUCTION. I > don't know if it's crucial to have a dedicated control file state for > end-of-recovery checkpoints. Please note that end-of-recovery can take a while in production systems (we have observed such things working with our customers) and anything can happen during that period of time. The end-of-recovery checkpoint is not something that gets finished momentarily. Therefore, having a separate db state in the control file is useful. Regards, Bharath Rupireddy.