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 ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d02a9084d91015547b831385fc007b6ac0161be5 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(+)
