Re: Failing assertion while taking a restartpoint during crash recovery

On Sun, Aug 16, 2026 at 02:14:32AM +0900, Fujii Masao wrote:
> I agree that adding such new recovery state variables basically would
> not be a good idea. But, I don't think the flag introduced by this patch
> falls into that category. It simply tracks whether pg_subtrans has been
> started during recovery, so I don't have much concern about adding it.

I am not concerned with the addition of this new flag. You are
outsourcing a check based on ArchiveRecoveryRequested *and*
EnableHotStandby to rely on a single state once we have called
StartupSUBTRANS(), so you are simplifying the recovery logic. This
argument counts as a +1 here.

What I do see an an issue is that the script used in the report is
mentioned as a link on github. If this content is lost, we would also
lose the history related to this thread. Attaching it here for the
sake of the archives. That's a better practice in general.

Fujii-san, how did you reproduce the problem? Just by reusing the
script? If we've failed detected this defect for so many years,
perhaps this warrants a test? If it proves to be expensive in terms
of cycles, I'd be a bit meh. Perhaps it can be made cheap, even if I
suspect that injection points cannot be used: we need something that
would be set up at very early startup.

One question that has not been raised is if exposing this new flag has
any value for pg_stat_recovery. This could not be a v19 item, perhaps
a v20 item. I don't see how useful it would be as it is no better
than connections getting accepted by the postmaster once a hot standby
is set up (flag would be always true at SQL level).
--
Michael