From 9eb5607e69933f0a88b6774d1ba728f27afdbd3d Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Wed, 24 Jul 2019 20:24:05 +0300 Subject: Refactor checks for deleted GiST pages. The explicit check in gistScanPage() isn't currently really necessary, as a deleted page is always empty, so the loop would fall through without doing anything, anyway. But it's a marginal optimization, and it gives a nice place to attach a comment to explain how it works. Backpatch to v12, where GiST page deletion was introduced. Reviewed-by: Andrey Borodin Discussion: https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru --- src/backend/access/gist/gistget.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'src/backend/access/gist/gistget.c') diff --git a/src/backend/access/gist/gistget.c b/src/backend/access/gist/gistget.c index 46d08e06350..4e0c500a22e 100644 --- a/src/backend/access/gist/gistget.c +++ b/src/backend/access/gist/gistget.c @@ -377,6 +377,20 @@ gistScanPage(IndexScanDesc scan, GISTSearchItem *pageItem, double *myDistances, MemoryContextSwitchTo(oldcxt); } + /* + * Check if the page was deleted after we saw the downlink. There's + * nothing of interest on a deleted page. Note that we must do this + * after checking the NSN for concurrent splits! It's possible that + * the page originally contained some tuples that are visible to us, + * but was split so that all the visible tuples were moved to another + * page, and then this page was deleted. + */ + if (GistPageIsDeleted(page)) + { + UnlockReleaseBuffer(buffer); + return; + } + so->nPageData = so->curPageData = 0; scan->xs_hitup = NULL; /* might point into pageDataCxt */ if (so->pageDataCxt) -- cgit v1.2.3