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

From Matthias van de Meent
Subject Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Date
Msg-id CAEze2WgnHJF66BtviDFNCPy26gLrb+tfns-Bi62DBfReH0-UCg@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>)
List pgsql-hackers
On Fri, 21 Mar 2025 at 17:14, Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> 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.

And here's v12. v11 (skipped) would've been a rebase, but after
finishing the rebase I noticed a severe regression in btree's IOS with
the new code, so v12 here applies some optimizations which reduce the
overhead of the new code.

Given its TableAM api changes it'd be nice to have a review on 0001,
though the additions could be rewritten to not (yet) add
TableAMRoutine.

I think patches 1, 2 and 3 are relevant to PG18 (as long as we don't
have a beta, and this is only a bit more than a bugfix). Patch 4 is
for PG19 to get btree to implement the new API, too, and patch 5
contains tests similar to the bitmap scan tests, validating that IOS
doesn't block VACUUM but still returns correct results.

I'll try to figure out a patch that's backpatchable, as alternative to
patches 2 and 3, or at least for back-patching into PG17-. That will
arrive separately, though.


Kind regards,

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

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
Next
From: Masahiko Sawada
Date:
Subject: Re: Fix premature xmin advancement during fast forward decoding