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

Michail Nikolaev <michail.nikolaev@gmail.com>

From: Michail Nikolaev <michail.nikolaev@gmail.com>

To: Matthias van de Meent <boekewurm+postgres@gmail.com>

Cc: Peter Geoghegan <pg@bowt.ie>, pgsql-hackers@lists.postgresql.org, hlinnaka@iki.fi, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas@vondra.me>

Date: 2025-02-05T10:11:40Z

Lists: pgsql-hackers

Attachments

v7-0004-This-should-fix-issues-with-incorrect-results-whe.patch (application/octet-stream) patch v7-0004
v7-0002-This-should-fix-issues-with-incorrect-results-whe.patch (application/octet-stream) patch v7-0002
v7-0003-Also-add-ability-to-set-LP_DEAD-bits-in-more-case.patch (application/octet-stream) patch v7-0003
v7-0001-isolation-tester-showing-broken-index-only-scans-.patch (application/octet-stream) patch v7-0001

Ooops, missed one commit - fixed (logic related to LP_DEAD in GIST
extracted to separate commit).

Also, commitfest entry is here - https://commitfest.postgresql.org/52/5542/

>

Commits

Standardize cleanup lock terminology.
- bcf60585e6e0 15.0 landed
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited