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

Commit0d3ad65

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 parent9cbbf07 commit0d3ad65

File tree

1 file changed

+17
-12
lines changed

1 file changed

+17
-12
lines changed

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

Lines changed: 17 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,7 @@
1919
#include"miscadmin.h"
2020
#include"utils/datum.h"
2121
#include"utils/memutils.h"
22+
#include"utils/rel.h"
2223

2324
/* GUC parameter */
2425
intGinFuzzySearchLimit=0;
@@ -247,24 +248,28 @@ collectMatchBitmap(GinBtreeData *btree, GinBtreeStack *stack,
247248
/* Search forward to re-find idatum */
248249
for (;;)
249250
{
250-
DatumnewDatum;
251-
GinNullCategorynewCategory;
252-
253251
if (moveRightIfItNeeded(btree,stack)== false)
254-
elog(ERROR,"lost saved point in index");/* must not happen !!! */
252+
ereport(ERROR,
253+
(errcode(ERRCODE_INTERNAL_ERROR),
254+
errmsg("failed to re-find tuple within index \"%s\"",
255+
RelationGetRelationName(btree->index))));
255256

256257
page=BufferGetPage(stack->buffer);
257258
itup= (IndexTuple)PageGetItem(page,PageGetItemId(page,stack->off));
258259

259-
if (gintuple_get_attrnum(btree->ginstate,itup)!=attnum)
260-
elog(ERROR,"lost saved point in index");/* must not happen !!! */
261-
newDatum=gintuple_get_key(btree->ginstate,itup,
262-
&newCategory);
260+
if (gintuple_get_attrnum(btree->ginstate,itup)==attnum)
261+
{
262+
DatumnewDatum;
263+
GinNullCategorynewCategory;
264+
265+
newDatum=gintuple_get_key(btree->ginstate,itup,
266+
&newCategory);
263267

264-
if (ginCompareEntries(btree->ginstate,attnum,
265-
newDatum,newCategory,
266-
idatum,icategory)==0)
267-
break;/* Found! */
268+
if (ginCompareEntries(btree->ginstate,attnum,
269+
newDatum,newCategory,
270+
idatum,icategory)==0)
271+
break;/* Found! */
272+
}
268273

269274
stack->off++;
270275
}

0 commit comments

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