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

Commitff3c16d

Browse files
committed
Fix code for re-finding scan position in a multicolumn GIN index.
collectMatchBitmap() needs to re-find the index tuple it was previouslylooking at, after transiently dropping lock on the index page it's on.The tuple should still exist and be at its prior position or somewhereto the right of that, since ginvacuum never removes tuples butconcurrent insertions could add one. However, there was a thinko inthat logic, to the effect of expecting any inserted tuples to have thesame index "attnum" as what we'd been scanning. Since there's nophysical separation of tuples with different attnums, it's not terriblyhard to devise scenarios where this fails, leading to transient "lostsaved point in index" errors. (While I've duplicated this with manualtesting, it seems impossible to make a reproducible test case with ouravailable testing technology.)Fix by just continuing the scan when the attnum doesn't match.While here, improve the error message used if we do fail, so that itmatches the wording used in btree for a similar case.collectMatchBitmap()'s posting-tree code path was previously notexercised at all by our regression tests. While I can't makea regression test that exhibits the bug, I can at least improvethe code coverage here, so do that. The test case I made for thisis an extension of one added by4b754d6, so it only works inHEAD and v13; didn't seem worth trying hard to back-patch it.Per bug #16595 from Jesse Kinkead. This has been broken sincemulticolumn capability was added to GIN (commit27cb66f),so back-patch to all supported branches.Discussion:https://postgr.es/m/16595-633118be8eef9ce2@postgresql.org
1 parentfa3bd8d commitff3c16d

File tree

1 file changed

+16
-12
lines changed

1 file changed

+16
-12
lines changed

‎src/backend/access/gin/ginget.c

Lines changed: 16 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -264,24 +264,28 @@ collectMatchBitmap(GinBtreeData *btree, GinBtreeStack *stack,
264264
/* Search forward to re-find idatum */
265265
for (;;)
266266
{
267-
DatumnewDatum;
268-
GinNullCategorynewCategory;
269-
270267
if (moveRightIfItNeeded(btree,stack,snapshot)== false)
271-
elog(ERROR,"lost saved point in index");/* must not happen !!! */
268+
ereport(ERROR,
269+
(errcode(ERRCODE_INTERNAL_ERROR),
270+
errmsg("failed to re-find tuple within index \"%s\"",
271+
RelationGetRelationName(btree->index))));
272272

273273
page=BufferGetPage(stack->buffer);
274274
itup= (IndexTuple)PageGetItem(page,PageGetItemId(page,stack->off));
275275

276-
if (gintuple_get_attrnum(btree->ginstate,itup)!=attnum)
277-
elog(ERROR,"lost saved point in index");/* must not happen !!! */
278-
newDatum=gintuple_get_key(btree->ginstate,itup,
279-
&newCategory);
276+
if (gintuple_get_attrnum(btree->ginstate,itup)==attnum)
277+
{
278+
DatumnewDatum;
279+
GinNullCategorynewCategory;
280+
281+
newDatum=gintuple_get_key(btree->ginstate,itup,
282+
&newCategory);
280283

281-
if (ginCompareEntries(btree->ginstate,attnum,
282-
newDatum,newCategory,
283-
idatum,icategory)==0)
284-
break;/* Found! */
284+
if (ginCompareEntries(btree->ginstate,attnum,
285+
newDatum,newCategory,
286+
idatum,icategory)==0)
287+
break;/* Found! */
288+
}
285289

286290
stack->off++;
287291
}

0 commit comments

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