For about fifteen years the answer to “can I turn on data checksums without an initdb?” has been “not really.” pg_checksums showed up in PostgreSQL 12 and made the job survivable, but you still had to shut the cluster down. For anyone running 24×7 production, that has left the same three options: take the downtime, fail over through a checksummed replica, or live without checksums.
PostgreSQL 19 adds a fourth path. A commit from Daniel Gustafsson on April 3rd wires up online enabling and disabling of data checksums: the command completes immediately, and the cluster keeps serving traffic while a background process rewrites every heap and index page in the cluster to carry (or drop) the checksum.
This is a genuinely big feature. It is also a feature that will burn you if you treat the SQL command as instantaneous and move on.
What is actually happening
The command flips a cluster-level state. Nothing on disk changes when it returns. A background process then walks every relation, reads each page into shared buffers, stamps the checksum, and writes the page back out. Indexes get the same treatment. Everything is logged through WAL, which means replication traffic spikes for the duration — on a large cluster, significantly — and your backup footprint does too.
If you interrupt this in the middle, the cluster is in a mixed state: some pages checksummed, some not. That is safe. It is not, however, a state you want to stay in indefinitely, because the visible checksum status does not switch to “on” until the conversion finishes.
What it costs
Plan for something between a minor-version upgrade and a VACUUM FULL on the entire cluster. The I/O envelope is closer to the latter. On a multi-terabyte cluster with respectable provisioned IOPS, the conversion will run for hours and will compete directly with autovacuum, the regular workload, and any backup job running at the same time. On a cloud instance with burst IOPS, it will exhaust the burst budget early and then throttle. Expect replication lag.
What to do
Do this. But do it like any other long-running, I/O-heavy operation: run it during a quiet window, confirm autovacuum has nothing pressing, make sure your backup window does not overlap, and watch pg_stat_io and replica lag for the duration. Do not assume “online” means “free.”
If you are currently running without checksums on a cluster older than a few hundred gigabytes, this is the feature that finally makes it worth turning them on. The diagnostic value of a checksum failure during a real corruption event is enormous, and the cost of waiting until something goes wrong is larger than one quiet weekend of background rewrites.
If you are already on checksums, this mostly matters as a recovery option. You can now disable and re-enable them without an outage if a recovery playbook needs it.
Retire the pg_checksums offline playbook.