Horton

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

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Michail Nikolaev <michail.nikolaev@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, 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-28T01:53:19Z
Lists: pgsql-hackers 
On Sat, Feb 8, 2025 at 8:47 AM Michail Nikolaev
<michail.nikolaev@gmail.com> wrote:
> Just some commit messages + few cleanups.

I'm worried about this:

+These longer pin lifetimes can cause buffer exhaustion with messages like "no
+unpinned buffers available" when the index has many pages that have similar
+ordering; but future work can figure out how to best work that out.

I think that we should have some kind of upper bound on the number of
pins that can be acquired at any one time, in order to completely
avoid these problems. Solving that problem will probably require GiST
expertise that I don't have right now.

-- 
Peter Geoghegan

Commits

  1. Standardize cleanup lock terminology.

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