Horton
Menu

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

Andrey Borodin <x4mmm@yandex-team.ru>

View thread
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>, Andres Freund <andres@anarazel.de>, Matthias van de Meent <boekewurm+postgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2026-06-27T10:41:25Z
Lists: pgsql-hackers 

> On 27 Jun 2026, at 01:05, Robert Haas <robertmhaas@gmail.com> wrote:
> 
> Apparently these patches are based on an old commit, or you have some
> other local patches. Can you specify a commit to apply them to, and/or
> rebase?

v3 set applies cleanly on REL_18_STABLE. +1 on backpatching this. 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).

Did I get it right that we will not have this

+ * Backwards compatibility path. Previously, the VM buffers were

on v19?


Best regards, Andrey Borodin.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revamp the WAL record format.

  2. Allow I/O reliability checks using 16-bit checksums

  3. Make the visibility map crash-safe.