rdelaage/postgresql
1
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-09-27 22:52:07 +02:00
Code Issues Packages Projects Releases Wiki Activity

Correct _bt_delitems_vacuum() lock comments.

Browse Source 
The expectation within _bt_delitems_vacuum() is that caller has a
super-exclusive/cleanup buffer lock (not just a pin and a write lock).
This commit is contained in:
Peter Geoghegan 2020-01-02 13:30:40 -08:00
parent 1fa846f1c9
commit 44e44bd258
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/access/nbtree/nbtpage.c
View File

@ -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