Horton

Re: Changing the state of data checksums in a running cluster

SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>

View thread
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
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>
Date: 2026-05-01T16:57:20Z
Lists: pgsql-hackers

Attachments

Hi Daniel,

On Thu, Apr 30, 2026 at 8:20 AM Daniel Gustafsson <daniel@yesql.se> wrote:

> > On 29 Apr 2026, at 15:42, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
> wrote:
>
> > The patchset looks good.
>
> Thanks for review, I've applied the patchset after some editorializing.
>

While further testing this feature, I realized that
ProcessSingleRelationFork()
unconditionally called log_newpage_buffer() for every page of every
relation
during pg_enable_data_checksums(). This included unlogged relations,
which by definition never generate WAL for data changes and are reset to
their
init fork on any recovery.

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.

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,
Satya