Gotchas about pg_verify_checksums - Mailing list pgsql-hackers

From Michael Paquier
Subject Gotchas about pg_verify_checksums
Date
Msg-id 20180410042147.GB1552@paquier.xyz
Whole thread Raw
Responses Re: Gotchas about pg_verify_checksums
List pgsql-hackers
Hi all,

I have not been giving much attention to the thread about enabling
checksums online, which has resulted in the revert of the feature, but
there is still pg_verify_checksums around.  So I looked at it a bit.

I have a couple of questions/gotchas about it:
1) The documentation states that the cluster needs to be offline.
Doesn't this imply that the cluster can also be forcibly killed?  It
seems to me that the documentation ought to say that the cluster needs
to be shut down cleanly instead.  Mentioning that only in the notes of
the documentation would be enough in my opinion.
2) On a cluster where checksums are disabled, aka the control file says
so, then using --force does not result in incorrect blocks to be
reported.  This is caused by the presence of the check on
PG_DATA_CHECKSUM_VERSION which does not match for a cluster where
checksums have been disabled.  Wouldn't one want to know this
information as well to know what are the portions of the data folder not
treated yet by checksum updates?
3) Is the force option actually useful?  I assume that --force is useful
if one wants to check how checksums are computed if a switch off -> on
is used to see the progress of the operation or to see how much progress
has been done after doing an online switch, which is also what a228cc13
outlines.  Still this requires the cluster to be offline...

Attached is a patch which addresses point 1) (with one markup fix in
bonus).  I'd love to get more input about the other bullet points.

Thanks,
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [sqlsmith] Failed assertion on pfree() viaperform_pruning_combine_step
Next
From: Amit Langote
Date:
Subject: Re: pruning disabled for array, enum, record, range type partitionkeys