Correct _bt_delitems_vacuum() lock comments.

petergeoghegan · petergeoghegan · commit 44e44bd258a7 · 2020-01-02T13:30:40.000-08:00
The expectation within _bt_delitems_vacuum() is that caller has a
super-exclusive/cleanup buffer lock (not just a pin and a write lock).
diff --git 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

Original file line number	Diff line number	Diff line change
`@@ -967,8 +967,9 @@ _bt_page_recyclable(Page page)`
`967`	`967`	`* non-leaf page has to be done as part of an atomic action that includes`
`968`	`968`	`* deleting the page it points to.`
`969`	`969`	`*`
`970`		`- * This routine assumes that the caller has pinned and locked the buffer.`
`971`		`- * Also, the given deletable array must be sorted in ascending order.`
	`970`	`+ * This routine assumes that the caller has a super-exclusive write lock on`
	`971`	`+ * the buffer. Also, the given deletable array must be sorted in ascending`
	`972`	`+ * order.`
`972`	`973`	`*`
`973`	`974`	`* We record VACUUMs and b-tree deletes differently in WAL. Deletes must`
`974`	`975`	`* generate recovery conflicts by accessing the heap inline, whereas VACUUMs`
`@@ -1049,8 +1050,9 @@ _bt_delitems_vacuum(Relation rel, Buffer buf,`
`1049`	`1050`	`*`
`1050`	`1051`	`* As above, must only be used on leaf pages.`
`1051`	`1052`	`*`
`1052`		`- * This routine assumes that the caller has pinned and locked the buffer.`
`1053`		`- * Also, the given itemnos must appear in increasing order in the array.`
	`1053`	`+ * This routine assumes that the caller has pinned and write locked the`
	`1054`	`+ * buffer. Also, the given itemnos must appear in increasing order in the`
	`1055`	`+ * array.`
`1054`	`1056`	`*`
`1055`	`1057`	`* This is nearly the same as _bt_delitems_vacuum as far as what it does to`
`1056`	`1058`	`* the page, but it needs to generate its own recovery conflicts by accessing`