Fix RI fast-path race with REINDEX CONCURRENTLY The RI fast path reads pg_constraint.conindid before taking RowShareLock on the referenced table. REINDEX CONCURRENTLY can repoint the constraint and mark the old index dead, or drop it, between those operations. A backend in that window does not yet hold a relation lock, so it is not covered by REINDEX CONCURRENTLY's waits for lockers.
Opening an index that has already been dropped produces "could not open relation with OID". Opening one that has only been marked dead can produce wrong answers: the index is no longer maintained or vacuumed, so a scan can miss a referenced row or follow a stale entry to a reused heap line pointer. After locking the referenced table, reload the constraint and use its current conindid. LockRelationOid() processes invalidation messages after acquiring the lock, so the reload sees a committed index swap. If the lock was already held, REINDEX CONCURRENTLY cannot mark the old index dead or drop it until the transaction releases that lock, so continuing to use the old conindid is safe. Do this at both RI fast-path call sites. Add injection-point coverage for old indexes that have either been dropped or marked dead. Author: Mihail Nikalayeu <[email protected]> Discussion: https://postgr.es/m/cadzflwujivuv69uwuf5z4trmhnkvwquxw03q+uvnwmyfltj...@mail.gmail.com Backpatch-through: 19 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ec51b80b348fe34da15cfb991191ef0bdc4838c6 Modified Files -------------- src/backend/commands/indexcmds.c | 1 + src/backend/utils/adt/ri_triggers.c | 20 +++ src/test/modules/injection_points/Makefile | 1 + .../expected/ri_fastpath_reindex.out | 171 +++++++++++++++++++++ src/test/modules/injection_points/meson.build | 1 + .../specs/ri_fastpath_reindex.spec | 108 +++++++++++++ 6 files changed, 302 insertions(+)
