Re: Failing assertion while taking a restartpoint during crash recovery

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 <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Sat, Aug 15, 2026 at 4:57 PM Imran Zaheer <imran(dot)zhir(at)gmail(dot)com> 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