From 44e44bd258a71162444d41a1044c795f2c6dd3d1 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Thu, 2 Jan 2020 13:30:40 -0800 Subject: [PATCH] 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). --- src/backend/access/nbtree/nbtpage.c | 10 ++++++---- 1 file 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 -- 2.39.5