Coordinate PostgreSQL checksum changes across the replication set

Plan offline checksum changes as one coordinated operation across the PostgreSQL replication set.

Source facts

PostgreSQL 17 pg_checksums requires a server that has been cleanly shut down to check, enable, or disable data checksums. Enabling rewrites changed checksums in relation blocks; the cluster and other writers must remain stopped during that operation. For replication arrangements that directly copy relation blocks, such as pg_rewind, inconsistent checksum settings across nodes can lead to incorrect checksums. The documentation recommends changing all stopped clusters consistently or rebuilding standbys after changing the primary.

Source: PostgreSQL 17 — pg_checksums.

Applicability

This applies to PostgreSQL 17 offline checksum administration. It concerns a cluster-wide storage-format decision, not the separate manifest checks performed by pg_verifybackup on backup artifacts.

DSE recommendation

DSE recommends planning checksum changes as a coordinated maintenance event with an explicit node inventory. Record each node’s current setting, shutdown verification, the selected consistency strategy, and a restart order. Preserve the recovery prerequisites before modifying files. Assign one owner to confirm the entire replication set has reached the intended state, including any temporarily absent standby. Do not allow automation to restart a node while the offline operation or consistency checks remain incomplete.

Verification

Rehearse the selected strategy on disposable primary and standby clusters. Confirm clean shutdown, retain tool exit status and output, then verify settings and replication after restart or standby rebuild. Include a check that no unreviewed writer accessed the data directories during the offline work.

Official reference

PostgreSQL 17 — pg_checksums. Reviewed October 15, 2026.