Hi Mihail, On Wed, Aug 5, 2026 at 10:56 PM Mihail Nikalayeu <[email protected]> wrote: > > Hello, everyone! > > As was asked in [0] I have created a separate thread for [1]. > Also, I realized that [1] and [2] is the same issue (sorry, I lost a > bit in them all). > > Short quote from commit message: > > > The RI fast path looks up the constraint, takes RowShareLock on the > > referenced table, and opens the index conindid names. Reading conindid > > before that lock is not safe. REINDEX CONCURRENTLY repoints the > > constraint at a new index and then drops the old one, and it waits only > > for backends holding a lock on the referenced table; a backend that has > > read the constraint but not yet taken that lock is not one of them. It > > then opens an index that is already gone, and the write fails with > > "could not open relation with OID" > > Main patch\reproducer is v1-0001, nocfbox-X series also provide a > reproducer for the data corruption (though VACUUM is also involved).
Thanks. Attached is v2 of the patch posted here. I adjusted the commit message and comments, kept you credited as Author, and replaced the Opus co-author trailer with a disclosure sentence, which I can remove if you so prefer. I have noticed only one such disclosure in the commit log so far. I dropped the subtransaction permutation from the test suite because the pending subtransaction-batching patch [1] will duplicate the batched case. I briefly considered using ALTER TABLE validation to retain per-row coverage, but since it already holds the referenced-table lock, it cannot exercise the race the test case was meant to manifest. I will push this tomorrow. [1] https://postgr.es/m/ca+hiwqgha3tc6mzfslylrvwysdrmpkb1tqkh2jgd3htkggz...@mail.gmail.com -- Thanks, Amit Langote
v2-0001-Fix-RI-fast-path-race-with-REINDEX-CONCURRENTLY.patch
Description: Binary data
