Hi all,

While digging into the issues reported lately about REINDEX
CONCURRENTLY, I have bumped into the following, independent, issue:
/* Now open the relation of the new index, a lock is also needed on it */
newIndexRel = index_open(indexId, ShareUpdateExclusiveLock)

In this code path, indexId is the OID od the old index copied, and
newIndexId is the OID of the new index created.  So that's clearly
incorrect, and the comment even says the intention.  This causes for
example the same session lock to be taken twice on the old index, with
the new index remaining unprotected.

Any objections if I fix this issue as per the attached?
--
Michael
diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c
index e9da06a9fa..824e221a28 100644
--- a/src/backend/commands/indexcmds.c
+++ b/src/backend/commands/indexcmds.c
@@ -2960,8 +2960,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 lock is also needed
+		 * on it.
+		 */
+		newIndexRel = index_open(newIndexId, ShareUpdateExclusiveLock);
 
 		/*
 		 * Save the list of OIDs and locks in private context

Attachment: signature.asc
Description: PGP signature

Reply via email to