From d1f5a92e18dcfc750e9d338597e66af920aad99e Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 4 Dec 2010 13:47:08 -0500
Subject: [PATCH] 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.
---
src/backend/access/gist/gistget.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/backend/access/gist/gistget.c b/src/backend/access/gist/gistget.c
index afff55c7881..56921cfee01 100644
--- a/src/backend/access/gist/gistget.c
+++ b/src/backend/access/gist/gistget.c
@@ -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;
}
--
GitLab