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

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>

To: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>

Cc: Tomas Vondra <tomas@vondra.me>, Ayush Tiwari <ayushtiwari.slg01@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>, Bernd Helmle <mailings@oopsware.de>, Michael Paquier <michael@paquier.xyz>, Michael Banck <mbanck@gmx.net>

Date: 2026-05-05T13:46:03Z

Lists: pgsql-hackers

Attachments

0003-Fix-regex-searching-for-page-verification-failures-i.patch (application/octet-stream)
0002-Apply-data-checksum-worker-throttling-parameters.patch (application/octet-stream)
0001-Skip-WAL-for-unlogged-relations-during-online-checks.patch (application/octet-stream)
(unnamed) (text/plain)

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


I've tested your patch, and also expanded the test you wrote a little with a
persistence change.

> Further testing this feature, I noticed that the cost_delay and cost_limit arguments
>  to pg_enable_data_checksums() in practice have no effect.

Ugh, the API for updating the costs changed between when this code was written
and tested, and when it was committed (and since I was the one committing the
new API I really should've caught that). Thanks for the report and fix!

While hacking on your patches I realized that the regexes for finding page
verification failures in the logs were anchoring at the wrong point, the
attached 0003 fixes that.

Attached are editorialized versions of the patches, as well as my testfix, that
I'm planning to go ahead with.

--
Daniel Gustafsson