Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Date
Msg-id CAH2-WzkCSdOKOHfRX3irGfN1R_qig8eLi-tRrCFuain5RuNZUA@mail.gmail.com
Whole thread Raw
In response to Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Mon, Dec 2, 2024 at 8:18 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Attached is a refined version of a test case I posted earlier on [2],
> decisively proving that GiST index-only scans are in fact subtly
> broken. Right now it fails, showing a wrong answer to a query. The
> patch adds an isolationtest test case to btree_gist, based on a test
> case of Andres'.

I can confirm that the same bug affects SP-GiST. I modified the
original failing GiST isolation test to make it use SP-GiST instead,
proving what I already strongly suspected.

I have no reason to believe that there are any similar problems in
core index AMs other than GiST and SP-GiST, though. Let's go through
them all now: nbtree already does everything correctly, and all
remaining core index AMs don't support index-only scans *and* don't
support scans that don't just use an MVCC snapshot.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: code contributions for 2024, WIP version
Next
From: Rahul Pandey
Date:
Subject: Re: Waits monitoring