Re: Why clearing the VM doesn't require registering vm buffer in wal record

On Mon, Jun 29, 2026 at 3:47 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> I've done some mechanical checks on the 18 variant: the new 012_vm_consistency test is green
> (and goes red without the fix), and minor-version WAL compatibility holds:
> WAL replays both ways between patched and unpatched 18.4 (patched replays
> old-format records via the fallback path; unpatched harmlessly ignores the added
> VM block refs).

Thanks for the review.

> Did I get it right that we will not have this
>
> + * Backwards compatibility path. Previously, the VM buffers were
>
> on v19?

That's correct. The code in replay which clears the VM even if the VM
buffers aren't registered won't be there for 19/20.

> - The new t/012_vm_consistency.pl needs pg_visibility, but
> src/bin/pg_combinebackup/Makefile doesn't declare
> EXTRA_INSTALL=contrib/pg_visibility, so a standalone
> "make -C src/bin/pg_combinebackup check" fails with "extension pg_visibility
> is not available". (meson test and make check-world are fine, since they install
> the whole tree) (for example see how src/bin/pg_amcheck pulls amcheck/pageinspect)

Whoops! Thanks for finding this

> - A tiny wording nit: the comment on the retained visibilitymap_clear()
> says it's kept "for backwards compatibility". Maybe spell out that it's kept for
> ABI(prototype stability) on the back branches?

In the v4 I posted in a previous email, I updated the comment. The
funny thing is I actually didn't mean backwards compatibility to mean
prototype stability in the original comment you are referring to. I
meant that we use that function it in the backwards compatibility code
path, but it is true that we wouldn't want to change the behavior (not
taking locks) of an exposed function in back branches. Comment should
describe this now.

- Melanie