Skip to main content

PG.L7.DATA_CHECKSUMS_DISABLED — corruption from below is returned as data

  • Category: safety
  • Level: 7
  • Confidence: deterministic
  • Downtime class: none
  • Stability: stable
  • Suites: audit
  • Applies to: PostgreSQL 18

Data checksums verify a page when it is read. Corruption that originates below the database — a failing disk, a storage layer that lost a write, a bad memory module — is then detected and reported instead of being returned as data.

Without them, the same corruption arrives at your application as a perfectly ordinary value. There is no error to catch and no moment at which anybody learns.

Why this finding names a migration path instead of a setting​

Because there is no setting to change. On an existing cluster there is no in-place edit: pg_checksums --enable requires the cluster to be shut down cleanly, and the alternative is a new cluster and a dump/restore. That single requirement is the whole reason the finding describes a real path rather than proposing a one-line fix.

The decision is cheap at exactly one moment, which is why the example below is initdb.

Flagged​

initdb --no-data-checksums -D /var/lib/postgresql/data

Preferred​

initdb -D /var/lib/postgresql/data

PostgreSQL 18 initializes with checksums on. Turning them off is now an explicit choice, so their absence on an 18 cluster is either a deliberate opt-out or — far more often — an older cluster carried forward across an upgrade. Knowing which one you have is the actionable part.

Unreadable is not off​

A managed database that does not expose the value at all is reported as undetermined with a named reason, never as a failure. "We could not read it" and "it is off" are different sentences, and only one of them justifies planning a cluster migration.

One cluster, one answer​

This reads a cluster fact rather than a session value, so it is identical on a primary and on its replicas. It is not a separate finding on each.

Sources​