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

From vignesh C
Subject Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Date
Msg-id CALDaNm2RRDdsdf5U+Cc1LJc+DrpZwfX2JEa7NTkboyo2BAN0jA@mail.gmail.com
Whole thread Raw
In response to Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
List pgsql-hackers
On Sat, 8 Mar 2025 at 08:06, Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
>
> Here's a patchset that uses that approach. Naming of functions, types,
> fields and arguments TBD. The patch works and passes the new
> VACUUM-conflict tests, though I suspect the SP-GIST tests to have
> bugs, as an intermediate version of my 0003 patch didn't trigger the
> tests to fail, even though it did not hold a pin on (all) sorted
> items' data when it was being checked for visibility and/or returned
> from the scan.
>
> Patch 0001 details the important changes, while 0002/0003 use this new
> API to make GIST and SP-GIST's IOS work correctly when concurrent
> VACUUM is/was running.
> 0004 is the existing patch with tests (v8-0001).

I noticed that Mikhail's feedback from [1] is not yet addressed. I
have changed the status of the commitfest entry to Waiting on Author,
kindly address them and update the status to Needs review.
[1] - https://www.postgresql.org/message-id/CANtu0ojz0apXnVia0reTL28eL2=__ev8aLsiH=1XfD_Z3dnkTw@mail.gmail.com

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Incorrect result of bitmap heap scan.
Next
From: vignesh C
Date:
Subject: Re: Clarification on Role Access Rights to Table Indexes