From d8516db39dfa73042e3ba28f9efc78da4dd6792d Mon Sep 17 00:00:00 2001 From: Melanie Plageman Date: Tue, 22 Sep 2026 17:27:26 -0400 Subject: [PATCH] Assert correct VM page passed to pruning Before pruning a heap page, we get the current status of the corresponding VM page. If the passed in vmbuffer isn't the right one, visibilitymap_get_status() will silently unpin it and pin the correct page. Pruning assumes the caller manages the vmbuffer lifecycle, so this would leave the caller with a stale VM reference and would leak the new VM pin. To avoid mistakes in development, assert that the correct VM page is pinned before beginning. Reported-by: Melanie Plageman Reviewed-by: Andrey Borodin Discussion: https://postgr.es/m/CAAKRu_amj7qLF4c=9ijd=708Fu2G8gg-2EqwBu=aCdAHU2sPHg@mail.gmail.com Backpatch-through: 19 --- src/backend/access/heap/pruneheap.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c index 50f810c8830..c4db2e1335c 100644 --- a/src/backend/access/heap/pruneheap.c +++ b/src/backend/access/heap/pruneheap.c @@ -443,7 +443,13 @@ prune_freeze_setup(PruneFreezeParams *params, prstate->buffer = params->buffer; prstate->page = BufferGetPage(params->buffer); - Assert(BufferIsValid(params->vmbuffer)); + /* + * The caller must have pinned the VM page covering this heap block. If it + * doesn't have the correct page pinned, visibilitymap_get_status() will + * silently release the caller's pin and take its own, leaving the caller + * holding a stale buffer and leaking ours. + */ + Assert(visibilitymap_pin_ok(prstate->block, params->vmbuffer)); prstate->vmbuffer = params->vmbuffer; prstate->new_vmbits = 0; prstate->old_vmbits = visibilitymap_get_status(prstate->relation,