pgsql: Fix another bug in parent page splitting during GiST index build

From: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Fix another bug in parent page splitting during GiST index build
Date: 2023-09-26 12:53:15
Message-ID: E1ql7Yx-0063Yk-1g@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Fix another bug in parent page splitting during GiST index build.

Yet another bug in the ilk of commits a7ee7c851 and 741b88435. In
741b88435, we took care to clear the memorized location of the
downlink when we split the parent page, because splitting the parent
page can move the downlink. But we missed that even *updating* a tuple
on the parent can move it, because updating a tuple on a gist page is
implemented as a delete+insert, so the updated tuple gets moved to the
end of the page.

This commit fixes the bug in two different ways (belt and suspenders):

1. Clear the downlink when we update a tuple on the parent page, even
if it's not split. This the same approach as in commits a7ee7c851
and 741b88435.

I also noticed that gistFindCorrectParent did not clear the
'downlinkoffnum' when it stepped to the right sibling. Fix that
too, as it seems like a clear bug even though I haven't been able
to find a test case to hit that.

2. Change gistFindCorrectParent so that it treats 'downlinkoffnum'
merely as a hint. It now always first checks if the downlink is
still at that location, and if not, it scans the page like before.
That's more robust if there are still more cases where we fail to
clear 'downlinkoffnum' that we haven't yet uncovered. With this,
it's no longer necessary to meticulously clear 'downlinkoffnum',
so this makes the previous fixes unnecessary, but I didn't revert
them because it still seems nice to clear it when we know that the
downlink has moved.

Also add the test case using the same test data that Alexander
posted. I tried to reduce it to a smaller test, and I also tried to
reproduce this with different test data, but I was not able to, so
let's just include what we have.

Backpatch to v12, like the previous fixes.

Reported-by: Alexander Lakhin
Discussion: https://www.postgresql.org/message-id/18129-caca016eaf0c3702@postgresql.org

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/d7f521325f5db13c62749adc991cd16038385219

Modified Files
--------------
contrib/intarray/expected/_int.out | 91 +++++++++++++++++++
contrib/intarray/sql/_int.sql | 35 ++++++++
src/backend/access/gist/gist.c | 180 ++++++++++++++++++++-----------------
3 files changed, 226 insertions(+), 80 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2023-09-26 13:07:28 pgsql: Clean up MergeCheckConstraint()
Previous Message Peter Eisentraut 2023-09-26 10:34:14 pgsql: Add some const qualifiers