Hi, On Tue, May 5, 2026 at 6:46 AM Daniel Gustafsson <[email protected]> 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
