On Mon, Jun 29, 2026 at 3:47 AM Andrey Borodin <[email protected]> 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
