Fix two small bugs in new gistget.c logic.
1. Complain, rather than silently doing nothing, if an "invalid" tuple is found on a leaf page. Per off-list discussion with Heikki. 2. Fix oversight in code that removes a GISTSearchItem from the search queue: we have to reset lastHeap if this was the last heap item in the parent GISTSearchTreeItem. Otherwise subsequent additions will do the wrong thing. This was probably masked in early testing because in typical cases the parent item would now be completely empty and would be deleted on next call. You'd need a queued non-leaf page at exactly the same distance as a heap tuple to expose the bug.
This commit is contained in:
parent
387e468b82
commit
d1f5a92e18
|
@ -70,9 +70,10 @@ gistindex_keytest(IndexScanDesc scan,
|
|||
{
|
||||
int i;
|
||||
|
||||
if (GistPageIsLeaf(page)) /* shouldn't happen */
|
||||
elog(ERROR, "invalid GIST tuple found on leaf page");
|
||||
for (i = 0; i < scan->numberOfOrderBys; i++)
|
||||
so->distances[i] = -get_float8_infinity();
|
||||
*recheck_p = true; /* probably unnecessary */
|
||||
return true;
|
||||
}
|
||||
|
||||
|
@ -403,6 +404,8 @@ getNextGISTSearchItem(GISTScanOpaque so)
|
|||
{
|
||||
/* Delink item from chain */
|
||||
so->curTreeItem->head = item->next;
|
||||
if (item == so->curTreeItem->lastHeap)
|
||||
so->curTreeItem->lastHeap = NULL;
|
||||
/* Return item; caller is responsible to pfree it */
|
||||
return item;
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue