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

On Sun, 16 Mar 2025 at 13:58, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Sat, 8 Mar 2025 at 08:06, Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)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

While there has indeed been some feedback, so far I've been looking
for architectural feedback about how the bug would be solved, not per
se the names of variables, or the exact details of the comments on the
new code: I usually rather wait with polishing my patches until after
we've made sure it doesn't need a full rewrite due to architectural
issues (like what happened in the previous two iterations).

Attached is v10, which polishes the previous patches, and adds a patch
for nbtree to use the new visibility checking strategy so that it too
can release its index pages much earlier, and adds a similar
visibility check test to nbtree.

Kind regards,

Matthias van de Meent
Neon (https://neon.tech)