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
run_test.tar.gz
Description: application/gzip
signature.asc
Description: PGP signature
