Hi, While looking through recent SERIALIZABLE reports, I noticed that we now have several reproducible SSI problems in separate threads. Together, they form a useful bounded project for somebody who wants to learn this area: most already have a small reproducer, a proposed fix, or both, and the remaining questions overlap substantially.
I am listing the threads roughly in order of correctness impact and scope, both as a possible reading/review queue and to collect their current status in one place. * A uniqueness check using SnapshotDirty can rely on a concurrent deletion while the serializable transaction still sees the deleted row. This can let the transaction observe two rows with the same primary key and commit. The v1 patch extends table AM to report the deleting XID; it needs design review, particularly for an ABI-preserving back-branch variant. https://postgr.es/m/CA%2BCOZaBOiiRPmEfX00oE%3DN6HBSZVe0Y-y-ZqqaXq8BAAj1gu%2BQ%40mail.gmail.com * The original Jepsen anomaly was a test configuration issue, but its triage found that a serialization failure inside a subtransaction can be swallowed by ROLLBACK TO SAVEPOINT. Zsolt's v3 dooms the top-level transaction on all relevant error paths and looks ready for committer. https://postgr.es/m/CAN4CZFPsCjExDMdMaPXMDwnRZiyY%3D0ybL963xu8Z6RWvjqOLjA%40mail.gmail.com * Jacob found that after SSI summarization, OldCommittedSxact predicate locks can be ignored because they have no valid finishedBefore value. There is a deterministic injection-point test and a tentative fix using the commit sequence number stored in each summarized predicate lock. The overlap rule and backpatch treatment need review. https://postgr.es/m/CA%2BCOZaCtK%3DUQbeQwdAoRw27J%2B58bJBC%2ByNHP4OH2%2By_t2UtFAg%40mail.gmail.com * Josh reported that a transient InvalidTransactionId published while recalculating SxactGlobalXmin can make lockless readers skip required predicate-lock work. Mihail added a deterministic test. The current patch adds locks to the reader paths, including every page split, but the race can instead be removed at publication: calculate the new xmin and count locally, then publish them after scanning the active list. That preserves the existing lockless fast path and appears preferable. https://postgr.es/m/CAEkjoh2X8yL9TKrQKx6SL6gtMNuZsyH8K-%2BrE78EwdOv4oXjSA%40mail.gmail.com * INSERT ... ON CONFLICT has several related missing-read cases. Zsolt's v3 for DO SELECT uses an MVCC fetch before the tuple lock, avoiding the race in the earlier arbiter-probe patch. It now covers FOR KEY SHARE and WHERE false and looks ready for committer. DO NOTHING and filtered DO UPDATE on older branches still need corresponding treatment. https://postgr.es/m/CAN4CZFM1GkHJkpMeo4G5rxtacVsfeKCJYiik9E9AKX1E9VYQ1w%40mail.gmail.com * Jacob reported that TID range scans take no SIREAD lock and can commit write skew. A relation-level lock covers both existing tuples and inserts into gaps; page locks alone do not fit the current heap conflict checks. This needs a decision on that granularity and a backpatchable fix for PG14 and later. https://postgr.es/m/CA%2BCOZaBo%2BZpKgMvxcdACUjNtdYipe9Em06iX5KHLTVaTmFibiw%40mail.gmail.com * Alexander Lakhin reported an operational, rather than serialization-correctness, issue: temporary-relation cleanup can enter GetSafeSnapshot() during process exit and become uninterruptible behind a prepared serializable transaction. The proposed GetCatalogSnapshot() fix preserves the MVCC horizon needed by TOAST without enrolling the cleanup transaction in SSI. The v2 patch looks ready for committer. https://postgr.es/m/19441-ec29f3b1363b4a68%40postgresql.org Most of these threads already have small reproducers, tests, proposed fixes, and review from community contributors. Several have reached the point where another rebase or test run is unlikely to resolve the remaining question; they need a decision about an SSI invariant or safe backpatching. For a prospective committer, this looks like an opportunity to make one deep dive into one of PostgreSQL's distinctive subsystems and move several correctness fixes forward. Best regards, Andrey Borodin.
