In commit 276db875, I made vacuumlazy.c consistently use the term
"cleanup lock", rather than the term "super-exclusive lock". But on
further reflection I should have gone further, and removed the term
"super-exclusive lock" from the tree completely. The actual relevant C
symbols only use the term cleanup.
Attached patch does this. There's not much churn.
The term "super-exclusive lock" is far more likely to be used in index
AM code, particularly nbtree. That's why I, the nbtree person,
originally added a bunch of uses of that term in heapam -- prior to
that point heapam probably didn't use the term once.
Anyway, I don't think that there is a particularly good reason for an
index AM/table AM divide in terminology. In fact, I'd go further:
nbtree's use of super-exclusive locks is actually something that
exists for the benefit of heapam alone -- and so using a different
name in index AM code makes zero sense, because it's really a heapam
thing anyway. Despite appearances.
The underlying why we need a cleanup lock when calling
_bt_delitems_vacuum() (but not when calling the near-identical
_bt_delitems_delete() function) is this: we need it as an interlock,
to avoid breaking index-only scans with concurrent heap vacuuming (not
pruning) that takes place in vacuumlazy.c [1]. This issue isn't
currently documented anywhere, though I plan on addressing that in the
near future, with a separate patch.
Historic note: the reason why this issue is so confused now has a lot
to do with how the code has evolved over time. When the cleanup lock
thing was first added to nbtree way back in 2001 (see commit
c8076f09), there was no such thing as HOT, and nbtree didn't do
page-at-a-time processing yet -- I believe that the cleanup lock was
needed to avoid breaking these things (when lazy VACUUM became the
default). Of course the cleanup lock can't have been needed for
index-only scans back then, because there weren't any. I'm pretty sure
that that's the only remaining reason for requiring a cleanup lock.
Note about a future optimization opportunity: this also means that we
could safely elide the cleanup lock during VACUUM (just get an
exclusive lock) iff lazyvacuum.c told ambulkdelete that it has
*already* decided that it won't bother performing a round of heap
VACUUM in lazy_vacuum_heap_rel(). This observation isn't useful on its
own, but in a world with something like Robert Haas's conveyor belt
design (a world with *selective* index vacuuming), it could be quite
valuable.
[1] https://postgr.es/m/CAH2-Wz=PqOziyRSrnN5jAtfXWXY7-BJcHz9S355LH8Dt=5qxWQ@mail.gmail.com
--
Peter Geoghegan
