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