Hi, I agree that tracking whether StartupSUBTRANS() has actually been called is more direct and robust. I don't have any strong objection to your approach; your fix looks reasonable to me.
My initial concern was more about having too many recovery state management variables at this point, i.e., ArchiveRecoveryRequested, InArchiveRecovery, EnableHotStandby, StandbyMode, StandbyModeRequested, etc. I just wanted to keep the context close to the existing states and did not want to create a new state for this specific bug. Thanks, Imran Zaheer On Sat, Aug 15, 2026 at 4:10 PM Fujii Masao <[email protected]> wrote: > > On Sat, Aug 15, 2026 at 4:57 PM Imran Zaheer <[email protected]> wrote: > > > > Hi > > > > While doing some benchmarking related to my work with the recovery > > pipelining [1], I found that the checkpointer fails when trying to > > take a time-based restartpoint during the crash recovery. > > > > Right now I am facing this assertion failure. > > Thanks for the report! I was also able to reproduce the assertion failure. > > > It looks like the checkpointer is not aware of whether hot standby > > initialization was done during startup, which happens only in the case > > of ArchiveRecoveryRequested [2]. In this specific case, the > > checkpointer assumes hot standby initialization would have been done, > > so it tries to call TruncateSUBTRANS(). A simple fix is to add > > ArchiveRecoveryRequested to recovery shared memory XLogRecoveryCtl; > > then the checkpointer will simply skip TruncateSUBTRANS if archive > > recovery was not requested. I have attached my patch below. > > I think it would be better and more robust to check directly whether > StartupSUBTRANS() has already been called, rather than checking > ArchiveRecoveryRequested, as in the attached patch. > > Thoughts? > > Regards, > > -- > Fujii Masao
