Re: Why clearing the VM doesn't require registering vm buffer in wal record
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2026-03-06T16:49:20Z
Lists: pgsql-hackers
On Thu, Mar 5, 2026 at 7:43 PM Andres Freund <andres@anarazel.de> wrote: > Which perhaps also should have emitted an FPI when clearing a bit? But I'm > unsure that that was required at the time. OTOH, it did seem to generate an > FPI for setting a VM bit, so ... After booting up the part of my brain that worked on this back in 2011, I think I reasoned that clearing a bit was idempotent and didn't depend on the prior page state, so that we would be adequate protected without an FPI. I had to add a WAL record to *set* the VM bit, because that wasn't logged at all, but the actual of clearing the VM bit piggybacked on the heap change that necessitated doing so, and having that record also emit an FPI for the VM page didn't seem to me to add anything. So I think technically it's the addition of checksums that turns this into a real bug, because now torn pages are a checksum-failure hazard. However, that would have been extremely hard to notice given that I seem never to have actually documented that reasoning in a comment anywhere. I don't think we should mess around with trying to make the behavior here conditional on wal_level, checksums, etc. We should just do it all the time to keep the logic simple. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revamp the WAL record format.
- 2c03216d8311 9.5.0 cited
-
Allow I/O reliability checks using 16-bit checksums
- 96ef3b8ff1cf 9.3.0 cited
-
Make the visibility map crash-safe.
- 503c7305a1e3 9.2.0 cited