Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: Missing FSM Update when Updating VM On-access
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: 
 <CAAKRu_b2StZrEC=HmW8LePuQbczyFRnfs8qTAJwn_=W76-y24w@mail.gmail.com>
Date: Sat, 4 Jul 2026 23:41:07 +0500
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Andres Freund <andres@anarazel.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B4BE330-EE88-4C90-93CC-AA75DD127BE8@yandex-team.ru>
References: 
 <CAAKRu_b2StZrEC=HmW8LePuQbczyFRnfs8qTAJwn_=W76-y24w@mail.gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/2B4BE330-EE88-4C90-93CC-AA75DD127BE8%40yandex-team.ru>
Precedence: bulk


> On 30 Jun 2026, at 03:32, Melanie Plageman <melanieplageman@gmail.com> =
wrote:
>=20
> <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.