Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.2\))
Subject: Re: Changing the state of data checksums in a running cluster
From: Daniel Gustafsson <daniel@yesql.se>
In-Reply-To: 
 <CAHg+QDeGrpZbNZdLjd_T4b43xKEEXZN0HGhkFm-1bkBdyzK7AQ@mail.gmail.com>
Date: Fri, 1 May 2026 23:13:16 +0200
Cc: Ayush Tiwari <ayushtiwari.slg01@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Heikki Linnakangas <hlinnaka@iki.fi>,
 Tomas Vondra <tomas@vondra.me>,
 Andres Freund <andres@anarazel.de>,
 Bernd Helmle <mailings@oopsware.de>,
 Michael Paquier <michael@paquier.xyz>,
 Michael Banck <mbanck@gmx.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <525E0691-FDAD-4194-9228-592A2DB96749@yesql.se>
References: <7357A519-3391-4F07-BC69-5C9C2B120792@yesql.se>
 <477897AE-1314-4724-9694-0BABC4F4ABDA@yesql.se>
 <5mv5vtbqj2xm2wmevsi22smyn32jtznva3ya3daih3ixh3onex@s5fyab63xt3c>
 <2535E72D-5979-4F58-A2D3-2AA4AA335C20@yesql.se>
 <DEE0237A-D38C-477F-997C-3B0EB2D4FC57@yesql.se>
 <775fddbc-4dec-413d-89bb-1a8186858ee6@vondra.me>
 <683618b7-0946-400e-8066-97067f32d448@vondra.me>
 <C458D1B0-EF58-4DFC-9833-BC23D6B9C7F2@yesql.se>
 <daa95f1b-4dbd-4e03-a436-3ddd48b0fe56@vondra.me>
 <032619A2-D466-4A12-A524-98359D96AEA6@yesql.se>
 <300822bd-daeb-49e5-8af7-d7ce3af65adc@iki.fi>
 <BE93475D-504E-468E-867F-883749092DB9@yesql.se>
 <46d52594-fa93-4fbe-ad97-dc3127a04dd8@iki.fi>
 <EC4ED8A7-A9C5-4D92-B528-1303E97EEB48@yesql.se>
 <8B86AFB8-ACBC-44FC-A1AB-A58DB541A170@yesql.se>
 <452D5390-4F89-4DED-9835-8E9EA2A01E19@yesql.se>
 <c92b5d8b-bc03-47bc-b209-2e4a719eee32@iki.fi>
 <4020B0AE-6286-462F-BD50-3AAD170F08C9@yesql.se>
 <30E2C103-2F50-4F9D-8868-E057250F55CA@yesql.se>
 <A65FA3A1-A5B6-44E6-B726-2A7D3692B1A6@yesql.se>
 <d4265f6d-ae6a-4a52-999a-092a883d9f46@iki.fi>
 <B3162DDF-435A-4BFD-A99B-32A038F57051@yesql.se>
 <F2EA770C-275F-41B3-A6F8-9AB12FE12BFD@yesql.se>
 <CAHg+QDfRk4-S7DMmdbXJnQ-xF=sUpMAKuh8b83ObLqYVKx5QLA@mail.gmail.com>
 <17BD06EB-3741-4921-AF60-6575FB4784ED@yesql.se>
 <9197F930-DDEB-4CAC-82A2-16FEC715CCE8@yesql.se>
 <CAHg+QDfS0Ckw2HT-TWkdvB1pq9rrFzm1Pk_AUwuFL+Er23ZOFA@mail.gmail.com>
 <F78D7C71-A999-4604-B1B9-FE06D21E63C5@yesql.se>
 <CAJTYsWUq96LR=DSh0jcbZLwJekT06Z2PGND6GYaS0SANFC9E7A@mail.gmail.com>
 <6011EEE0-2D34-4A63-8B88-2437173486FE@yesql.se>
 <CAHg+QDeGrpZbNZdLjd_T4b43xKEEXZN0HGhkFm-1bkBdyzK7AQ@mail.gmail.com>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/525E0691-FDAD-4194-9228-592A2DB96749%40yesql.se>
Precedence: bulk

> On 1 May 2026, at 18:57, SATYANARAYANA NARLAPURAM =
<satyanarlapuram@gmail.com> wrote:

> While further testing this feature, I realized that =
ProcessSingleRelationFork()=20
> unconditionally called log_newpage_buffer() for every page of every =
relation=20
> during pg_enable_data_checksums(). This included unlogged relations,=20=

> which by definition never generate WAL for data changes and are reset =
to their
> init fork on any recovery.=20
>=20
> Guard the log_newpage_buffer() call with RelationNeedsWAL() so that
> unlogged relations still get their pages dirtied (ensuring the =
checksum
> is flushed to disk at the next checkpoint) but do not emit WAL.
>=20
> Attached a patch to address this and added a test for the same. My =
current
> test checks if standby has main fork, I could just checked WAL to =
verify this
> using pg_waldump. Any other test ideas are welcome.

Thanks for the report, I agree that this is an oversight that should be =
fixed.
Your patch looks good on first glance, I am travelling till Sunday =
evening so
will take another look when back in the office and will apply it then. =
Thanks!

--
Daniel Gustafsson