Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: cf/4997~1
Choose a base ref
...
head repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: cf/4997
Choose a head ref
  • 3 commits
  • 16 files changed
  • 2 contributors

Commits on Apr 18, 2025

  1. Add pg_control flag to prevent recovery without backup_label. 

    Harden recovery by adding a flag to pg_control to indicate that backup_label is
required. This prevents the user from deleting backup_label resulting in an
inconsistent recovery.

Another advantage is that the copy of pg_control used by pg_basebackup is
guaranteed not to be torn.

This functionality is limited to pg_basebackup (or any software comfortable
with modifying pg_control).

Control and catalog version bumps are required.
    @dwsteele
    dwsteele authored and Commitfest Bot committedApr 18, 2025
    Configuration menu
    Copy the full SHA
    bb87edcView commit details
    Browse the repository at this point in the history

  2. Return pg_control from pg_backup_stop(). 

    Harden recovery by returning a copy of pg_control from pg_backup_stop() that has
a flag set to prevent recovery if the backup_label file is missing. Instead of
backup software copying pg_control from PGDATA, it stores an updated version
that is returned from pg_backup_stop(). This is better for the following
reasons:

* The user can no longer remove backup_label and get what looks like a
successful recovery (while almost certainly causing corruption). If backup_label
is removed the cluster will not start. The user may try pg_resetwal, but that
tool makes it pretty clear that corruption will result from its use.

* We don't need to worry about backup software seeing a torn copy of pg_control,
since Postgres can safely read it out of memory and provide a valid copy via
pg_backup_stop(). This solves torn reads without needing to write pg_control via
a temp file, which may affect performance on a standby.

* For backup from standby, we no longer need to instruct the backup software to
copy pg_control last. In fact the backup software should not copy pg_control from
PGDATA at all.

These changes have no impact on current backup software and they are free to use
the pg_control available from pg_stop_backup() or continue to use pg_control from
PGDATA. Of course they will miss the benefits of getting a consistent copy of
pg_control and the backup_label checking, but will be no worse off than before.

Catalog version bump is required.
    @dwsteele
    dwsteele authored and Commitfest Bot committedApr 18, 2025
    Configuration menu
    Copy the full SHA
    15c5409View commit details
    Browse the repository at this point in the history

  3. [CF 4997] Return pg_control from pg_backup_stop(). 

    This branch was automatically generated by a robot using es from an
email thread registered at:

https://commitfest.postgresql.org//4997

The branch will be overwritten each time a new  version is posted to
the thread, and also periodically to check for bitrot caused by changes
on the master branch.

(es): https://www.postgresql.org/message-id/[email protected]
Author(s): David Steele
    Commitfest Bot committedApr 18, 2025
    Configuration menu
    Copy the full SHA
    7134c80View commit details
    Browse the repository at this point in the history
Loading