Re: Re-read conindid under the referenced table's lock in the RI fast path

Hi Mihail,

On Wed, Aug 5, 2026 at 10:56 PM Mihail Nikalayeu
<mihailnikalayeu(at)gmail(dot)com> 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+HiwqGHa3tc6MZFSLyLrvwySdrmpkb1TqkH2jGd3HtKGGZ6cQ@mail.gmail.com

--
Thanks, Amit Langote