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
signature.asc
Description: PGP signature