Re: Missing FSM Update when Updating VM On-access - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: Missing FSM Update when Updating VM On-access
Date
Msg-id CAAKRu_aLhWq+gtXWwjNMqTRVQ74HDtAoAAtDSb+1NFgseeppaQ@mail.gmail.com
Whole thread
In response to Re: Missing FSM Update when Updating VM On-access  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
On Sat, Jul 4, 2026 at 2:41 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
> 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.

Yea, I couldn't come up with a test that would behave.

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

I massaged the comments a bit. I originally omitted the other comment
because I was suspicious of it (see Andres' complaint about the
comment upthread). But I think I captured the part of it that we want
to preserve in my revised comments.

> Thanks for working on this!

Thanks for taking a look!

- Melanie



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Missing FSM Update when Updating VM On-access
Next
From: SATYANARAYANA NARLAPURAM
Date:
Subject: Reduce cleanup lock contention on standby replay