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

Commit7668d48

Browse files
committed
Acquire properly session-level lock on new index in REINDEX CONCURRENTLY
In the first transaction run for REINDEX CONCURRENTLY, a thinko in theexisting logic caused two session locks to be taken on the old index,causing the session lock on the newly-created index to be missed. Thismade possible concurrent DDL commands (like ALTER INDEX) on the newindex while REINDEX CONCURRENTLY was processing from the point where thefirst internal transaction committed.This issue has been discovered while digging into another bug.Author: Michael PaquierDiscussion:https://postgr.es/m/20191021074323.GB1869@paquier.xyzBackpatch-through: 12
1 parenta6a95d4 commit7668d48

File tree

1 file changed

+5
-2
lines changed

1 file changed

+5
-2
lines changed

‎src/backend/commands/indexcmds.c

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2961,8 +2961,11 @@ ReindexRelationConcurrently(Oid relationOid, int options)
29612961
indexId,
29622962
concurrentName);
29632963

2964-
/* Now open the relation of the new index, a lock is also needed on it */
2965-
newIndexRel=index_open(indexId,ShareUpdateExclusiveLock);
2964+
/*
2965+
* Now open the relation of the new index, a session-level lock is
2966+
* also needed on it.
2967+
*/
2968+
newIndexRel=index_open(newIndexId,ShareUpdateExclusiveLock);
29662969

29672970
/*
29682971
* Save the list of OIDs and locks in private context

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp