Acquire properly session-level lock on new index in REINDEX CONCURRENTLY

In the first transaction run for REINDEX CONCURRENTLY, a thinko in the
existing logic caused two session locks to be taken on the old index,
causing the session lock on the newly-created index to be missed.  This
made possible concurrent DDL commands (like ALTER INDEX) on the new
index while REINDEX CONCURRENTLY was processing from the point where the
first internal transaction committed.

This issue has been discovered while digging into another bug.

Author: Michael Paquier
Discussion: https://postgr.es/m/20191021074323.GB1869@paquier.xyz
Backpatch-through: 12

diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index 73e8b249e90f72a335a9c5a2a74837a9da81d81d..9c9ddd0fd78513fb61f1ca5832e9a9611aed6c46 100644 (file)
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -2961,8 +2961,11 @@ ReindexRelationConcurrently(Oid relationOid, int options)
                                                                                                        indexId,
                                                                                                        concurrentName);
 
-               /* Now open the relation of the new index, a lock is also needed on it */
-               newIndexRel = index_open(indexId, ShareUpdateExclusiveLock);
+               /*
+                * Now open the relation of the new index, a session-level lock is
+                * also needed on it.
+                */
+               newIndexRel = index_open(newIndexId, ShareUpdateExclusiveLock);
 
                /*
                 * Save the list of OIDs and locks in private context