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 F00E9F4E-6042-4CBA-8C8C-0863D4154E50@yesql.se
Whole thread
In response to Re: Changing the state of data checksums in a running cluster  (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>)
Responses Re: Changing the state of data checksums in a running cluster
Re: Changing the state of data checksums in a running cluster
List pgsql-hackers
> 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




Attachment

pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] pg_bsd_indent: improve formatting of multiline comments
Next
From: SATYANARAYANA NARLAPURAM
Date:
Subject: Re: Changing the state of data checksums in a running cluster