PG_CHECKSUMS_EXT(1)

πŸ’– pg_checksums_ext β€” the checksum glow-up page πŸ’–

okay so bestie, welcome to pg_checksums_ext from the Application manual section. she's a PostgreSQL girly whose whole personality is: enable, disable or check data checksums in a PostgreSQL database cluster. let's get into it πŸŽ€


✨ NAME ✨

pg_checksums_ext β€” enable, disable or check data checksums in a PostgreSQL database cluster. no cap, that's literally the whole job description πŸ’…


🌸 SYNOPSIS 🌸

pg_checksums_ext [option...] [[-D | --pgdata] datadir]

πŸ¦‹ DESCRIPTION πŸ¦‹

so pg_checksums_ext checks, enables or disables data checksums in a PostgreSQL cluster. simple queen behaviour.

here's the tea though β€” the server must be shut down when you're enabling or disabling checksums 🫒 but verifying checksums? that can be done online. main character energy fr.

when you're verifying checksums, the exit status is zero if there are no checksum errors, and nonzero if at least one checksum failure is detected. when you're enabling or disabling checksums, the exit status is nonzero if the operation failed. periodt.

when verifying checksums, every file in the cluster is scanned. when enabling checksums, each relation file block with a changed checksum is rewritten in-place. disabling checksums only updates the file pg_control β€” she's low-effort like that ✨


πŸ’… OPTIONS πŸ’…

the following command-line options are available:

  • -D directory, --pgdata=*directory* β€” tells you where the database cluster lives. like, her address bestie πŸ’–
  • -c, --check β€” checks checksums. this is the default mode if nothing else is specified, so if you just vibe and pass nothing, this is what you get πŸŽ€
  • -d, --disable β€” disables checksums. bye girl πŸ‘‹
  • -e, --enable β€” enables checksums. welcome back queen πŸ‘‘
  • -f filenode, --filenode=*filenode* β€” only validate checksums in the relation with filenode filenode. selective, and honestly iconic for it 🌸
  • -N, --no-sync β€” by default, pg_checksums_ext will wait for all files to be written safely to disk. this option causes pg_checksums_ext to return without waiting, which is faster, but means that a subsequent operating system crash can leave the updated data directory corrupt 😭 generally, this option is useful for testing but should not be used on a production installation. this option has no effect when using --check.
okay so fr fr, don't be cute with -N on prod. she will betray you πŸ’€
  • -P, --progress β€” enable progress reporting. turning this on will deliver a progress report while checking or enabling checksums. progress reporting can also be triggered by the SIGUSR1 signal β€” so if you wanna poke her mid-run, that works too πŸ”₯
  • --max-rate=*rate* β€” set a maximum I/O rate (in MB/s) while checking or enabling checksums. throttle her, respectfully 🌈
  • -v, --verbose β€” enable verbose output. lists all checked files. she's gonna name names, every single one πŸ“
  • --debug β€” enable debug output. for when you need the deep lore πŸ”
  • -V, --version β€” print the pg_checksums_ext version and exit. flex the fit πŸ’…
  • -?, --help β€” show help about pg_checksums_ext command line arguments, and exit. she'll explain herself 🫢

🌈 ENVIRONMENT 🌈

  • PGDATA β€” specifies the directory where the database cluster is stored; can be overridden using the -D option.
  • PG_COLOR β€” specifies whether to use color in diagnostics messages. possible values are always, auto, never. aesthetic choices, we love to see it 🎨

πŸ’œ NOTES πŸ’œ

enabling checksums in a large cluster can potentially take a long time. during this operation, the cluster or other programs that write to the data directory must not be started or else data loss may occur. not a drill bestie, do not open the club while she's working 🚫

when using a replication setup with tools which perform direct copies of relation file blocks (for example pg_rewind), 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. when enabling or disabling checksums in a replication setup, it is thus recommended to stop all the clusters before switching them all consistently. destroying all standbys, performing the operation on the primary and finally recreating the standbys from scratch is also safe. so like, either everyone stops together or it's a full reset, no in-between πŸ™ˆ

if pg_checksums_ext is aborted or killed while enabling or disabling checksums, the cluster's data checksum configuration remains unchanged, and pg_checksums_ext can be re-run to perform the same operation. she's got resilience, we stan a recoverable queen πŸ’–


okay that's the whole page bestie!! this was Application, dated 2025-10-08, and it's the PG_CHECKSUMS_EXT(1) manual β€” go forth and checksum responsibly, mwah πŸŽ€βœ¨πŸ’œ

πŸ“¦ where this page comes from