| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Open SSI correctness issues |
| Date: | 2026-08-28 13:00:58 |
| Message-ID: | 4BE33B3F-8E83-40EF-94BE-24467212D0D8@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-08-28 13:14:17 | Re: pg_stat_get_autovacuum_scores ignores the main table's reloptions for TOAST tables |
| Previous Message | Nisha Moond | 2026-08-28 12:30:24 | Re: Proposal: Conflict log history table for Logical Replication |