postgresql.git/src/backend/backup, branch REL_19_STABLE

Revert online data checksum transitions

2026-09-16T09:01:27Z

The feature to enable, or disable, data checksums in an online cluster saw a number of postcommit fixes during the beta period. Suspicions were raised about the risk of more issues surfacing after GA. To avoid shipping code which may have bugs, this reverts in full, or in part, the following commits: aaf8b9989f7, cd857dec0e0, 5fee7cab1b8, 25b922ec582, 8fb8ded8895, b3a37ffbc5b, abac86c7a27, 3a18526e8d6, 01805b7d16b, 343d98c3601, e469e4784ea, 8d22f523245, e5e1f6dc795, 5ab239c9a90, 0ca1b301059, 9a39056c418, 2018bd61679, 1df361e3d82, bf25e5571b3, 381d19da153, b120358c612, 07009121c23, d771b0a907e, f19c0eccae9, 0907112d388, 397f0fd06ed, 602f19c84ca, e3a27cad462, 4ae3e98c02c, b364828f825 A few bits remain as they have merit on their own: * The fix for offline checksums not preserving initial state in pg_control_init. The test case for this fix has been moved to src/bin/pg_checksums/t/002_actions.pl to survive the revert which removed the previous location. * When a page verification is logged, the additional note which informs if the buffer will be zeroed out was kept to aid any debugging around checksum failures. * The Data Checksum section in the docs was kept, but rewritten to reflect the current state. * The enum containing checksum states is kept and some hardcoded references to the off state (0) are replaced with the label PG_DATA_CHECKSUM_OFF instead. Discussion: https://postgr.es/m/E15AC050-C4B5-488D-BB2D-3C7AC9F89EA8@yesql.se Discussion: https://postgr.es/m/anwm6UPxoVS41QA2@bdtpg Discussion: https://postgr.es/m/CA+Tgmob9NY6m0YNFTQ4nFH2d0iC9SQRruDYxfndGKKzh8OC80w@mail.gmail.com Discussion: https://postgr.es/m/E07A611B-9CF3-4FDB-8CE8-A221E39040EC%40yesql.se

Report single-page checksum failures in pg_stat_database

2026-08-19T00:51:52Z

Base backups reported checksum failures to pg_stat_database only for files with more than one failing page. Commit 6b9e875f728 placed the report inside the block emitting the per-file summary WARNING, which was skipped for a single failure. As a result, a backup failing on files with one corrupted page each left checksum_failures untouched. To fix, emit the per-file summary and the pgstat report for any non-zero failure count. The end-of-backup total WARNING had the same off-by-one and is now also emitted for a single failure. Author: Zsolt Parragi Reviewed-by: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAN4CZFN+Bi6XmaH8zOdMWjoycYFx9nKtOr+dzQf0o-UQ+Rdqmw@mail.gmail.com Backpatch-through: 14

basebackup: do not verify checksums on pages from before enabling

2026-08-18T20:25:52Z

Enabling data checksums in a running cluster changes the state to "on" before the checkpoint which flushes the pages the worker rewrote. A base backup which started before that transition absorbs the barrier mid-run and starts verifying pages whose on-disk copies legitimately lack checksums, and whose LSNs predate the backup start, so the LSN check does not skip them either. The backup fails with bogus corruption warnings. The same applies to checksums being disabled and re-enabled while the backup runs: hint bits set while checksums were off reach disk without a checksum update and without moving the page LSN, tripping verification once the re-enabling completes. To fix, verify checksums only while they have been continuously enabled since the checkpoint the backup started from: track the location of the last XLOG2_CHECKSUMS record inserted or replayed, and verify only when the state is "on" and the last change predates the backup start. The starting checkpoint then guarantees that every page flushed before it has a checksum written, and any later change disables verification for the rest of the backup. A standby loses the tracked location when restarting, while pg_control already carries the new state, so it could reach consistency below the record and serve base backups with the location unknown. To prevent this, replaying XLOG2_CHECKSUMS advances minRecoveryPoint to the record, like XLOG_PARAMETER_CHANGE does. The tests hold the enabling between the state change and its final checkpoint with injection points, straddling it with backups on the primary and across a standby crash-restart. Author: Zsolt Parragi Reviewed-by: Bertrand Drouvot Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/CAN4CZFP=-cVVVPue+e8qqPtDfuLuQn=ZB4Mw_C9-Ncru2wqAsQ@mail.gmail.com Backpatch-through: 19

Clear base backup progress on backup failure

2026-07-01T14:05:04Z

Previously, if a base backup failed after it had started streaming files, pg_stat_progress_basebackup could continue to show a stale progress entry even though the backup was no longer running. This could be observed when the client kept the replication connection open after the error. It is normally not observable when using pg_basebackup, because the client disconnects after the error. The problem was that progress reporting was cleared only after successful completion. This commit moves the progress reporting cleanup into the progress sink's cleanup callback so that it is cleared after both successful and failed backups. Backpatch to v15. v14 has the same issue, but the fix does not apply cleanly because it lacks the base backup sink infrastructure. Since the bug does not affect the backup itself and is normally not observable when using pg_basebackup, skip the v14 backpatch. Author: Chao Li Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/EA1A6CD2-EFA6-462B-9A02-03003555AB4A@gmail.com Backpatch-through: 15

Don't cast off_t to 32-bit type for output, bug fix

2026-07-01T07:40:16Z

off_t is most likely a 64-bit integer, so casting it to a 32-bit type for output could lose data. There are more issues like this in the tree, but this is an instance where this could actually happen in practice, since base backups are routinely larger than 4 GB. So this is separated out as a bug fix. Reviewed-by: Heikki Linnakangas Discussion: https://www.postgresql.org/message-id/flat/20ce62fa-47fc-457b-b504-12f3c1651726%40eisentraut.org

Pre-beta mechanical code beautification, step 1: run pgindent.

2026-05-13T14:34:17Z

Update typedefs.list from the buildfarm, and run pgindent. The changes from the new typedefs list are pretty minimal, since we'd been pretty good (not perfect) about updating typedefs.list by hand. But the pgindent behavior changes installed by a3e6beba6, b518ba4af, and 60f9467c3 add up to make this a relatively sizable diff.

Online enabling and disabling of data checksums

2026-04-03T20:58:51Z

This allows data checksums to be enabled, or disabled, in a running cluster without restricting access to the cluster during processing. Data checksums could prior to this only be enabled during initdb or when the cluster is offline using the pg_checksums app. This commit introduce functionality to enable, or disable, data checksums while the cluster is running regardless of how it was initialized. A background worker launcher process is responsible for launching a dynamic per-database background worker which will mark all buffers dirty for all relation with storage in order for them to have data checksums calculated on write. Once all relations in all databases have been processed, the data_checksums state will be set to on and the cluster will at that point be identical to one which had data checksums enabled during initialization or via offline processing. When data checksums are being enabled, concurrent I/O operations from backends other than the data checksums worker will write the checksums but not verify them on reading. Only when all backends have absorbed the procsignalbarrier for setting data_checksums to on will they also start verifying checksums on reading. The same process is repeated during disabling; all backends write checksums but do not verify them until the barrier for setting the state to off has been absorbed by all. This in-progress state is used to ensure there are no false negatives (or positives) due to reading a checksum which is not in sync with the page. A new testmodule, test_checksums, is introduced with an extensive set of tests covering both online and offline data checksum mode changes. The tests which run concurrent pgbdench during online processing are gated behind the PG_TEST_EXTRA flag due to being very expensive to run. Two levels of PG_TEST_EXTRA flags exist to turn on a subset of the expensive tests, or the full suite of multiple runs. This work is based on an earlier version of this patch which was reviewed by among others Heikki Linnakangas, Robert Haas, Andres Freund, Tomas Vondra, Michael Banck and Andrey Borodin. During the work on this new version, Tomas Vondra has given invaluable assistance with not only coding and reviewing but very in-depth testing. Author: Daniel Gustafsson Author: Magnus Hagander Co-authored-by: Tomas Vondra Reviewed-by: Tomas Vondra Reviewed-by: Andres Freund Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/CABUevExz9hUUOLnJVr2kpw9Cx=o4MCr1SVKwbupzuxP7ckNutA@mail.gmail.com Discussion: https://postgr.es/m/20181030051643.elbxjww5jjgnjaxg@alap3.anarazel.de Discussion: https://postgr.es/m/CABUevEwE3urLtwxxqdgd5O2oQz9J717ZzMbh+ziCSa5YLLU_BA@mail.gmail.com

Add missing deflateEnd() for server-side gzip base backups

2026-03-23T00:04:44Z

The gzip basebackup sink called deflateInit2() in begin_archive() but never called deflateEnd(), leaking zlib's internal compression state (~256KB per archive) until the memory context of the base backup is destroyed. The code tree has already a matching deflateEnd() call for each deflateInit[2]() call (pgrypto, etc.), except for the file touched in this commit, so this brings more consistency for all the compression methods. The server-side LZ4 and zstd implementations require a dedicated cleanup callback as they allocate their state outside the context of a palloc(). As currently used, deflateInit2() is called once per tablespace in a single backup. Memory would slightly bloat only when dealing with many tablespaces at once, not across multiple base backups so this is not worth a backpatch. This change could matter for future uses of this code. zlib allows the definition of memory allocation and free callbacks in the z_stream object given to a deflateInit[2](). The base backup backend code relies on palloc() for the allocations and deflateEnd() internally only cleans up memory (no fd allocation for example). Author: Jianghua Yang Discussion: https://postgr.es/m/CAAZLFmQNJ0QNArpWEOZXwv=vbumcWKEHz-b1me5gBqRqG67EwQ@mail.gmail.com

Reduce header inclusions via execnodes.h

2026-03-16T13:34:57Z

Remove a bunch of #include lines from execnodes.h. Most of these requier suitable typedefs to be added, so that it still compiles standalone. In one case, the fix is to move a struct definition to the one .c file where it is needed. Also some light clean up in plannodes.h and genam.h, though not as extensive as in execnodes.h. Author: Álvaro Herrera Author: Andres Freund Discussion: https://postgr.es/m/202603131240.ihwqdxnj7w2o@alvherre.pgsql

Add all required calls to TupleDescFinalize()

2026-03-15T22:45:49Z

As of this commit all TupleDescs must have TupleDescFinalize() called on them once the TupleDesc is set up and before BlessTupleDesc() is called. In this commit, TupleDescFinalize() does nothing. This change has only been separated out from the commit that properly implements this function to make the change more obvious. Any extension which makes its own TupleDesc will need to be modified to call the new function. The follow-up commit which properly implements TupleDescFinalize() will cause any code which forgets to do this to fail in assert-enabled builds in BlessTupleDesc(). It may still be worth mentioning this change in the release notes so that extension authors update their code. Author: David Rowley Reviewed-by: Chao Li Reviewed-by: Andres Freund Reviewed-by: John Naylor Reviewed-by: Amit Langote Reviewed-by: Zsolt Parragi Reviewed-by: Álvaro Herrera Reviewed-by: Junwang Zhao Discussion: https://postgr.es/m/CAApHDvpoFjaj3%2Bw_jD5uPnGazaw41A71tVJokLDJg2zfcigpMQ%40mail.gmail.com