Horton

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

vignesh C <vignesh21@gmail.com>

View thread View on postgr.es
From: vignesh C <vignesh21@gmail.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, Michail Nikolaev <michail.nikolaev@gmail.com>, pgsql-hackers@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas@vondra.me>
Date: 2025-03-16T12:58:17Z
Lists: 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

Commits

  1. Standardize cleanup lock terminology.

  2. Reduce pinning and buffer content locking for btree scans.