On Fri, Sep 3, 2021 at 10:23 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Thu, 2 Sep 2021 11:30:59 -0400, Robert Haas <robertmh...@gmail.com> wrote > in > > On Mon, Aug 9, 2021 at 3:00 PM Robert Haas <robertmh...@gmail.com> wrote: > > > I decided to try writing a patch to use an end-of-recovery record > > > rather than a checkpoint record in all cases. > > > > > > The first problem I hit was that GetRunningTransactionData() does > > > Assert(TransactionIdIsNormal(CurrentRunningXacts->latestCompletedXid)). > > > > > > Unfortunately we can't just relax the assertion, because the > > > XLOG_RUNNING_XACTS record will eventually be handed to > > > ProcArrayApplyRecoveryInfo() for processing ... and that function > > > contains a matching assertion which would in turn fail. It in turn > > > passes the value to MaintainLatestCompletedXidRecovery() which > > > contains yet another matching assertion, so the restriction to normal > > > XIDs here looks pretty deliberate. There are no comments, though, so > > > the reader is left to guess why. I see one problem: > > > MaintainLatestCompletedXidRecovery uses FullXidRelativeTo, which > > > expects a normal XID. Perhaps it's best to just dodge the entire issue > > > by skipping LogStandbySnapshot() if latestCompletedXid happens to be > > > 2, but that feels like a hack, because AFAICS the real problem is that > > > StartupXLog() doesn't agree with the rest of the code on whether 2 is > > > a legal case, and maybe we ought to be storing a value that doesn't > > > need to be computed via TransactionIdRetreat(). > > > > Anyone have any thoughts about this? > > I tried to reproduce this but just replacing the end-of-recovery > checkpoint request with issuing an end-of-recovery record didn't cause > make check-workd fail for me. Do you have an idea of any other > requirement to cause that? >
You might need the following change at the end of StartupXLOG(): - if (promoted) - RequestCheckpoint(CHECKPOINT_FORCE); + RequestCheckpoint(CHECKPOINT_FORCE); Regards, Amul
