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

Hi,

On Tue, May 5, 2026 at 6:46 AM Daniel Gustafsson <daniel(at)yesql(dot)se> 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.
>
>
> 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!
>

Any thoughts on adding an injection point test to verify the values are
configured correctly?
This can be a different patch, perhaps included in Tomas' tests?

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

LGTM. Thanks!

Thanks,
Satya