> On 30 Jun 2026, at 03:32, Melanie Plageman <melanieplageman@gmail.com> wrote:
>
> <v1-0001-Update-FSM-after-updating-VM-on-access.patch>
Hi Melanie,
I applied the patch ("Update FSM after updating VM on-access") and it does
what it says. On a single node, on-access pruning now sets the VM and
refreshes the FSM to the post-prune free space, matching what a plain VACUUM
records (in my run summed avail 3200000 -> 7360000, VM 10000|0). On a
primary + streaming standby the FSM comes out identical on both sides after
replay (in this simple test) - i.e. the primary now records what the standby
already writes in heap_xlog_prune_freeze.
A dedicated test would be nice but is difficult here: on-access VM-setting is
nondeterministic (see the enum/plancache flakiness earlier), and even a TAP
test with autovacuum off + forced horizon advancement would likely be
unstable on the buildfarm - so it might even be net negative.
One comment nit: the reserve behavior is preserved (we skip the FSM update
unless the page became newly_all_visible), but the outer comment explaining
*why* we don't update the FSM in the common case is gone; the rationale now
survives only as a parenthetical inside the `if (presult.newly_all_visible)`
block. A one-line note at the point where we *skip* the update would spare a
future reader from wondering why it isn't unconditional.
Thanks for working on this!
Best regards, Andrey Borodin.
