Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 0326635

Browse files
committed
Fix bug in detecting concurrent page splits in GiST insert
In commit 9eb5607, I got the condition on checking for split or deleted page wrong: I used && instead of ||. The comment correctly said "concurrent split _or_ deletion". As a result, GiST insertion could miss a concurrent split, and insert to wrong page. Duncan Sands demonstrated this with a test script that did a lot of concurrent inserts. Backpatch to v12, where this was introduced. REINDEX is required to fix indexes that were affected by this bug. Backpatch-through: 12 Reported-by: Duncan Sands Discussion: https://www.postgresql.org/message-id/a9690483-6c6c-3c82-c8ba-dc1a40848f11%40deepbluecap.com
1 parent 5ad672f commit 0326635

File tree

1 file changed

+4
-1
lines changed

1 file changed

+4
-1
lines changed

src/backend/access/gist/gist.c

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -242,6 +242,9 @@ gistplacetopage(Relation rel, Size freespace, GISTSTATE *giststate,
242242
if (GistFollowRight(page))
243243
elog(ERROR, "concurrent GiST page split was incomplete");
244244

245+
/* should never try to insert to a deleted page */
246+
Assert(!GistPageIsDeleted(page));
247+
245248
*splitinfo = NIL;
246249

247250
/*
@@ -857,7 +860,7 @@ gistdoinsert(Relation r, IndexTuple itup, Size freespace,
857860
*/
858861
}
859862
else if ((GistFollowRight(stack->page) ||
860-
stack->parent->lsn < GistPageGetNSN(stack->page)) &&
863+
stack->parent->lsn < GistPageGetNSN(stack->page)) ||
861864
GistPageIsDeleted(stack->page))
862865
{
863866
/*

0 commit comments

Comments
 (0)