Correct _bt_delitems_vacuum() lock comments.

The expectation within _bt_delitems_vacuum() is that caller has a
super-exclusive/cleanup buffer lock (not just a pin and a write lock).

1 files changed, 6 insertions, 4 deletions

diff --git a/src/backend/access/nbtree/nbtpage.c b/src/backend/access/nbtree/nbtpage.c
index 52a214ed974..73d28d37a3f 100644
--- a/src/backend/access/nbtree/nbtpage.c
+++ b/src/backend/access/nbtree/nbtpage.c
@@ -967,8 +967,9 @@ _bt_page_recyclable(Page page)
  * non-leaf page has to be done as part of an atomic action that includes
  * deleting the page it points to.
  *
- * This routine assumes that the caller has pinned and locked the buffer.
- * Also, the given deletable array *must* be sorted in ascending order.
+ * This routine assumes that the caller has a super-exclusive write lock on
+ * the buffer.  Also, the given deletable array *must* be sorted in ascending
+ * order.
  *
  * We record VACUUMs and b-tree deletes differently in WAL.  Deletes must
  * generate recovery conflicts by accessing the heap inline, whereas VACUUMs
@@ -1049,8 +1050,9 @@ _bt_delitems_vacuum(Relation rel, Buffer buf,
  *
  * As above, must only be used on leaf pages.
  *
- * This routine assumes that the caller has pinned and locked the buffer.
- * Also, the given itemnos *must* appear in increasing order in the array.
+ * This routine assumes that the caller has pinned and write locked the
+ * buffer.  Also, the given itemnos *must* appear in increasing order in the
+ * array.
  *
  * This is nearly the same as _bt_delitems_vacuum as far as what it does to
  * the page, but it needs to generate its own recovery conflicts by accessing