Re: Speed up pg_checksums in cases where checksum already set

In one of the checksum patches, there was an understanding that the pages
should be written even if the checksum is correct, to handle replicas.

From the v19 patch:
https://www.postgresql.org/message-id/F7AFCFCD-8F77-4546-8D42-C7F675A4B680%40yesql.se
+                * Mark the buffer as dirty and force a full page write.  We have to
+                * re-write the page to WAL even if the checksum hasn't changed,
+                * because if there is a replica it might have a slightly different
+                * version of the page with an invalid checksum, caused by unlogged
+                * changes (e.g. hintbits) on the master happening while checksums
+                * were off. This can happen if there was a valid checksum on the page
+                * at one point in the past, so only when checksums are first on, then
+                * off, and then turned on again.

pg_checksums(1) says:

|       When using a replication setup with tools which perform direct copies of relation file blocks (for example
pg_rewind(1)),enabling or disabling checksums can lead to page
 
|       corruptions in the shape of incorrect checksums if the operation is not done consistently across all nodes.
Whenenabling or disabling checksums in a replication setup, it
 
|       is thus recommended to stop all the clusters before switching them all consistently. Destroying all standbys,
performingthe operation on the primary and finally recreating
 
|       the standbys from scratch is also safe.

Does your patch complicate things for the "stop all the clusters before
switching them all" case?

-- 
Justin