Skip to content

Commit 523ecaf

Browse files
committed
Correct predicate locking for DROP INDEX CONCURRENTLY.
For the non-concurrent case there is an AccessExclusiveLock lock on both the index and the heap at a time during which no other process is using either, before which the index is maintained and used for scans, and after which the index is no longer used or maintained. Predicate locks can safely be moved from the index to the related heap relation under the protection of these locks. This was done prior to the introductin of DROP INDEX CONCURRENTLY and continues to be done for non-concurrent index drops. For concurrent index drops, the predicate locks must be moved when there are no index scans in progress on that index and no more can subsequently start, and before heap inserts stop maintaining the index. As long as these conditions are guaranteed when the TransferPredicateLocksToHeapRelation() function is called, stronger locks are not needed for correctness. Kevin Grittner based on questions by Tom Lane in reviewing the DROP INDEX CONCURRENTLY patch and in cooperation with Andres Freund and Simon Riggs. Back-patch of commit 4c9d090
1 parent a4ef1f0 commit 523ecaf

File tree

1 file changed

+22
-6
lines changed

1 file changed

+22
-6
lines changed

src/backend/catalog/index.c

Lines changed: 22 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1322,6 +1322,18 @@ index_drop(Oid indexId, bool concurrent)
13221322
* In the concurrent case we make sure that nobody can be looking at the
13231323
* indexes by dropping the index in multiple steps, so we don't need a full
13241324
* AccessExclusiveLock yet.
1325+
*
1326+
* All predicate locks on the index are about to be made invalid. Promote
1327+
* them to relation locks on the heap. For correctness the index must not
1328+
* be seen with indisvalid = true during query planning after the move
1329+
* starts, so that the index will not be used for a scan after the
1330+
* predicate lock move, as this could create new predicate locks on the
1331+
* index which would not ensure a heap relation lock. Also, the index must
1332+
* not be seen during execution of a heap tuple insert with indisready =
1333+
* false before the move is complete, since the conflict with the
1334+
* predicate lock on the index gap could be missed before the lock on the
1335+
* heap relation is in place to detect a conflict based on the heap tuple
1336+
* insert.
13251337
*/
13261338
heapId = IndexGetRelation(indexId, false);
13271339
if (concurrent)
@@ -1446,6 +1458,14 @@ index_drop(Oid indexId, bool concurrent)
14461458
old_lockholders++;
14471459
}
14481460

1461+
/*
1462+
* No more predicate locks will be acquired on this index, and we're
1463+
* about to stop doing inserts into the index which could show
1464+
* conflicts with existing predicate locks, so now is the time to move
1465+
* them to the heap relation.
1466+
*/
1467+
TransferPredicateLocksToHeapRelation(userIndexRelation);
1468+
14491469
/*
14501470
* Now we are sure that nobody uses the index for queries, they just
14511471
* might have it opened for updating it. So now we can unset
@@ -1516,12 +1536,8 @@ index_drop(Oid indexId, bool concurrent)
15161536
userHeapRelation = heap_open(heapId, ShareUpdateExclusiveLock);
15171537
userIndexRelation = index_open(indexId, AccessExclusiveLock);
15181538
}
1519-
1520-
/*
1521-
* All predicate locks on the index are about to be made invalid. Promote
1522-
* them to relation locks on the heap.
1523-
*/
1524-
TransferPredicateLocksToHeapRelation(userIndexRelation);
1539+
else
1540+
TransferPredicateLocksToHeapRelation(userIndexRelation);
15251541

15261542
/*
15271543
* Schedule physical removal of the files

0 commit comments

Comments
 (0)