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

From Peter Geoghegan
Subject Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Date
Msg-id CAH2-Wznyb4m1h40DycQqaDe3a3z=YkdsGGGfcX+YjC8J64d7=A@mail.gmail.com
Whole thread Raw
In response to Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?  (Peter Geoghegan <pg@bowt.ie>)
List 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



pgsql-hackers by date:

Previous
From: Andy Alsup
Date:
Subject: Re: Update docs for UUID data type
Next
From: Thomas Munro
Date:
Subject: Re: Confine vacuum skip logic to lazy_scan_skip