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=5q...@mail.gmail.com -- Peter Geoghegan
v1-0001-Deprecate-the-term-super-exclusive-lock.patch
Description: Binary data
