SSI's HeapCheckForSerializableConflictOut() test failed to correctly handle conditions involving a concurrently inserted tuple which is later concurrently updated by a separate transaction . A SELECT statement that called HeapCheckForSerializableConflictOut() could end up using the same XID (updater's XID) for both the original tuple, and the successor tuple, missing the XID of the xact that created the original tuple entirely. This only happened when neither tuple from the chain was
visible to the transaction's MVCC snapshot.
The observable symptoms of this bug were subtle. A pair of transactions could commit, with the later transaction failing to observe the effects of the earlier transaction (because of the confusion created by the update to the non-visible row). This bug dates all the way back to commit dafaa3ef, which added SSI.
To fix, make sure that we check the xmin of concurrently inserted tuples that happen to also have been updated concurrently.
Author: Peter Geoghegan
5940ffb221 Avoid update conflict out serialization anomalies.
src/backend/access/heap/heapam.c | 21 +++++++--
.../isolation/expected/update-conflict-out.out | 27 +++++++++++
src/test/isolation/isolation_schedule | 1 +
src/test/isolation/specs/update-conflict-out.spec | 54 ++++++++++++++++++++++
4 files changed, 98 insertions(+), 5 deletions(-)