Horton

Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)

Kirill Reshke <reshkekirill@gmail.com>

View thread
From: Kirill Reshke <reshkekirill@gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Chao Li <li.evan.chao@gmail.com>
Date: 2025-12-18T18:07:20Z
Lists: pgsql-hackers

Attachments

On Thu, 18 Dec 2025 at 20:18, Melanie Plageman
<melanieplageman@gmail.com> wrote:

> But you are right, I don't see any non-error code path where a heap
> page would become empty (all line pointers set unused) and then not be
> set all-visible. Only vacuum sets line pointers unused and if all the
> line pointers are unused it will always set the page all-visible.
>
> I think, though, that if we error out in lazy_scan_prune() after
> returning from heap_page_prune_and_freeze() such that we don't set the
> empty page all-visible, we can end up with an empty page without
> PD_ALL_VISIBLE set. You can see how this might work by patching the VM
> set code in lazy_scan_prune() to skip empty pages.
>

Thank you for your explanation!  I completely forgot that PD_ALL_VIS
is a non-persistent change (hint bit). so its update can be trivially
lost.
The simplest real-life example is being killed just after returning
from heap_page_prune_and_freeze, yes.
PFA tap test covering lazy_scan_new_or_empty code path for
empty-but-not-all-visible page

-- 
Best regards,
Kirill Reshke