From 7668d48477edc3bc8d6990ac3d3bd79e327e2719 Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Wed, 23 Oct 2019 15:05:09 +0900 Subject: [PATCH] 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 --- src/backend/commands/indexcmds.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c index 73e8b249e9..9c9ddd0fd7 100644 --- 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