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