Re: Changing the state of data checksums in a running cluster - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Changing the state of data checksums in a running cluster
Date
Msg-id 525E0691-FDAD-4194-9228-592A2DB96749@yesql.se
Whole thread
In response to Re: Changing the state of data checksums in a running cluster  (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>)
List pgsql-hackers
> On 1 May 2026, at 18:57, SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> wrote:

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




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10
Next
From: Nathan Bossart
Date:
Subject: Re: problems with toast.* reloptions