Fix waits of REINDEX CONCURRENTLY for indexes with predicates or expressions

As introduced by f9900df5f94, a REINDEX CONCURRENTLY job done for an
index with predicates or expressions would set PROC_IN_SAFE_IC in its
MyProc->statusFlags, causing it to be ignored by other concurrent
operations.

Such concurrent index rebuilds should never be ignored, as a predicate
or an expression could call a user-defined function that accesses a
different table than the table where the index is rebuilt.

A test that uses injection points is added, backpatched down to 17.
Michail has proposed a different test, but I have added something
simpler with more coverage.

Oversight in f9900df5f949.

Author: Michail Nikolaev
Discussion: https://postgr.es/m/CANtu0oj9A3kZVduFTG0vrmGnKB+DCHgEpzOp0qAyOgmks84j0w@mail.gmail.com
Backpatch-through: 14

diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index 1d66376927fbbf240fcbbc4f26e47e86ddce1387..48b6c55e55d464a3f80e8f2422d93d68e2969b6f 100644 (file)
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -3680,8 +3680,8 @@ ReindexRelationConcurrently(Oid relationOid, ReindexParams *params)
                save_nestlevel = NewGUCNestLevel();
 
                /* determine safety of this index for set_indexsafe_procflags */
-               idx->safe = (indexRel->rd_indexprs == NIL &&
-                                        indexRel->rd_indpred == NIL);
+               idx->safe = (RelationGetIndexExpressions(indexRel) == NIL &&
+                                        RelationGetIndexPredicate(indexRel) == NIL);
                idx->tableId = RelationGetRelid(heapRel);
                idx->amId = indexRel->rd_rel->relam;