| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Why clearing the VM doesn't require registering vm buffer in wal record |
| Date: | 2026-03-06 16:49:20 |
| Message-ID: | CA+TgmoaUVzpbj+dgwnp5p49ieWTa3ZBHL=9GoHqh9cOCQ_2ghw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 5, 2026 at 7:43 PM Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2026-03-06 16:49:22 | Re: Rework SLRU I/O errors handle |
| Previous Message | Andrew Dunstan | 2026-03-06 16:41:03 | Re: Allow specifying NULL default in pg_proc.dat for "any" arguments |