Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)

On Wed, Oct 12, 2022 at 11:18 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> Please note that to pass the new regression tests, the fix proposed in
> a related thread[1] is required. Particularly, we need:
>
> @@ -1099,6 +1099,9 @@ SnapBuildCommitTxn(SnapBuild *builder,
> XLogRecPtr lsn, TransactionId xid,
> else if (sub_needs_timetravel)
> {
> /* track toplevel txn as well, subxact alone isn't meaningful */
> + elog(DEBUG2, "forced transaction %u to do timetravel
> due to one of its subtransaction",
> + xid);
> + needs_timetravel = true;
> SnapBuildAddCommittedTxn(builder, xid);
> }
> else if (needs_timetravel)
>
> A side benefit of this approach is that we can fix another assertion
> failure too that happens on REL14 and REL15 and reported here[2]. In
> the commits 68dcce247f1a(REL14) and 272248a0c1(REL15), the reason why
> we make the association between sub-txns to top-txn in
> SnapBuildXidSetCatalogChanges() is just to avoid the assertion failure
> in AssertTXNLsnOrder(). However, since the invalidation messages are
> not transported from sub-txn to top-txn during the assignment, another
> assertion check in ReorderBufferForget() fails when forgetting the
> subtransaction. If we apply this idea of skipping the assertion
> checks, we no longer need to make the such association in
> SnapBuildXidSetCatalogChanges() and resolve this issue as well.
>

IIUC, here you are speaking of three different changes. Change-1: Add
a check in AssertTXNLsnOrder() to skip assert checking till we reach
start_decoding_at. Change-2: Set needs_timetravel to true in one of
the else if branches in SnapBuildCommitTxn(). Change-3: Remove the
call to ReorderBufferAssignChild() from SnapBuildXidSetCatalogChanges
in PG-14/15 as that won't be required after Change-1.

AFAIU, Change-1 is required till v10; Change-2 and Change-3 are
required in HEAD/v15/v14 to fix the problem. Now, the second and third
changes are not required in branches prior to v14 because we don't
record invalidations via XLOG_XACT_INVALIDATIONS record. However, if
we want, we can even back-patch Change-2 and Change-3 to keep the code
consistent or maybe just Change-3.

Is my understanding correct?

--
With Regards,
Amit Kapila.