Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit4c9d090

Browse files
committed
Correct predicate locking for DROP INDEX CONCURRENTLY.
For the non-concurrent case there is an AccessExclusiveLock lockon both the index and the heap at a time during which no otherprocess is using either, before which the index is maintained andused for scans, and after which the index is no longer used ormaintained. Predicate locks can safely be moved from the index tothe related heap relation under the protection of these locks.This was done prior to the introductin of DROP INDEX CONCURRENTLYand continues to be done for non-concurrent index drops.For concurrent index drops, the predicate locks must be moved whenthere are no index scans in progress on that index and no more cansubsequently start, and before heap inserts stop maintaining theindex. As long as these conditions are guaranteed when theTransferPredicateLocksToHeapRelation() function is called,stronger locks are not needed for correctness.Kevin Grittner based on questions by Tom Lane in reviewing theDROP INDEX CONCURRENTLY patch and in cooperation with AndresFreund and Simon Riggs.
1 parentedef20f commit4c9d090

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
@@ -1320,6 +1320,18 @@ index_drop(Oid indexId, bool concurrent)
13201320
* In the concurrent case we make sure that nobody can be looking at the
13211321
* indexes by dropping the index in multiple steps, so we don't need a full
13221322
* AccessExclusiveLock yet.
1323+
*
1324+
* All predicate locks on the index are about to be made invalid. Promote
1325+
* them to relation locks on the heap. For correctness the index must not
1326+
* be seen with indisvalid = true during query planning after the move
1327+
* starts, so that the index will not be used for a scan after the
1328+
* predicate lock move, as this could create new predicate locks on the
1329+
* index which would not ensure a heap relation lock. Also, the index must
1330+
* not be seen during execution of a heap tuple insert with indisready =
1331+
* false before the move is complete, since the conflict with the
1332+
* predicate lock on the index gap could be missed before the lock on the
1333+
* heap relation is in place to detect a conflict based on the heap tuple
1334+
* insert.
13231335
*/
13241336
heapId=IndexGetRelation(indexId, false);
13251337
if (concurrent)
@@ -1444,6 +1456,14 @@ index_drop(Oid indexId, bool concurrent)
14441456
old_lockholders++;
14451457
}
14461458

1459+
/*
1460+
* No more predicate locks will be acquired on this index, and we're
1461+
* about to stop doing inserts into the index which could show
1462+
* conflicts with existing predicate locks, so now is the time to move
1463+
* them to the heap relation.
1464+
*/
1465+
TransferPredicateLocksToHeapRelation(userIndexRelation);
1466+
14471467
/*
14481468
* Now we are sure that nobody uses the index for queries, they just
14491469
* might have it opened for updating it. So now we can unset
@@ -1514,12 +1534,8 @@ index_drop(Oid indexId, bool concurrent)
15141534
userHeapRelation=heap_open(heapId,ShareUpdateExclusiveLock);
15151535
userIndexRelation=index_open(indexId,AccessExclusiveLock);
15161536
}
1517-
1518-
/*
1519-
* All predicate locks on the index are about to be made invalid. Promote
1520-
* them to relation locks on the heap.
1521-
*/
1522-
TransferPredicateLocksToHeapRelation(userIndexRelation);
1537+
else
1538+
TransferPredicateLocksToHeapRelation(userIndexRelation);
15231539

15241540
/*
15251541
* Schedule physical removal of the files

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp