Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Alexander Lakhin <exclusion@gmail.com>,
Masahiko Sawada <sawada.mshk@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-06-13T04:04:00Z
Lists: pgsql-hackers
On Wed, Jun 7, 2023 at 6:02 PM Tomas Vondra <tomas.vondra@enterprisedb.com> wrote: > > > Well, I think the issue is pretty clear - we end up with an initial > snapshot that's in between the ASSIGNMENT and NEW_CID, and because > NEW_CID has both xact and subxact XID it fails because we add two TXNs > with the same LSN, not realizing one of them is subxact. > > That's obviously wrong, although somewhat benign in production because > it only fails because of hitting an assert. > Doesn't this indicate that we can end up decoding a partial transaction when we restore a snapshot? Won't that be a problem even for production? > Regular builds are likely to > just ignore it, although I haven't checked if the COMMIT cleanup (I > wonder if we remove the subxact from the toplevel list on commit). > > I think the problem is we just grab an existing snapshot, before all > running xacts complete. Maybe we should fix that, and leave the > needs_full_snapshot alone. > It is not clear what exactly you have in mind to fix this because if there is no running xact, we don't even need to restore the snapshot because of a prior check "if (running->oldestRunningXid == running->nextXid)". I think the main problem is that we started decoding immediately from the point where we restored a snapshot as at that point we could have some partial running xacts. -- With Regards, Amit Kapila.
Commits
-
Fix executing invalidation messages generated by subtransactions during decoding.
- 343afa967106 15.1 landed
- 4fbe6096b954 14.6 landed
- 38dbaaf27387 13.9 landed
- 02600886c8a8 12.13 landed
- 216af69aec0d 11.18 landed
-
Fix assertion failures while processing NEW_CID record in logical decoding.
- 64ff0fe4e8c4 15.1 landed
- a592ed923e67 14.6 landed
- 25f7be1ca236 13.9 landed
- 1bf4d92060ee 12.13 landed
- 5f7076cb609e 11.18 landed
- 10ed7b9e4b19 10.23 landed
- 16b1fe0037dc 16.0 landed
-
Immediately WAL-log subtransaction and top-level XID association.
- 0bead9af484c 14.0 cited
-
Stop demanding that top xact must be seen before subxact in decoding.
- e3ff789acfb2 13.0 cited