Horton

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

Michail Nikolaev <michail.nikolaev@gmail.com>

View thread View on postgr.es
From: Michail Nikolaev <michail.nikolaev@gmail.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Peter Geoghegan <pg@bowt.ie>, 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-09T12:44:00Z
Lists: pgsql-hackers 
Hello, Mathias!

>  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

It all fails on master - could you please detail what is "intermediate" in
that case? Also, I think it is a good idea to add the same type of test to
btree.

>  * XXX: In the future we should probably reorder these operations so
>  * we can apply the checks in block order, rather than index order.

I think it is already done in your patch, no?

Should we when use that mechanics for btree as well? It seems to be
straight forward and non-invasive. In such case, "Unchecked" goes away, and
it is each AM responsibility to call the check while holding the pin.

Best regards,
Mikhail.

Commits

  1. Standardize cleanup lock terminology.

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