Re: Add recovery to pg_control and remove backup_label

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, David Steele <david@pgmasters.net>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-20T21:18:15Z
Lists: pgsql-hackers
On Mon, Nov 20, 2023 at 1:37 PM Andres Freund <andres@anarazel.de> wrote:

>
> Given that, I wonder if what we should do is to just add a new field to
> pg_control that says "error out if backup_label does not exist", that we
> set
> when creating a streaming base backup
>
>
I thought this was DOA since we don't want to ever leave the cluster in a
state where a crash requires intervention to restart.  But I agree that it
is not possible to fool-proof agaInst a naive backup that copies over the
pg_control file as-is if breaking the crashed cluster option is not in play.

I agree that this works if the pg_control generated by stop backup produces
the line and we retain the label file as a separate and now mandatory
component to using the backup.

Or is the idea to make v17 error if it sees a backup label unless
pg_control has the feature flag field?  Which doesn't exist normally, does
in the basebackup version, and is removed once the backup is restored?

David J.

Commits

  1. Doc: improve documentation for jsonpath behavior.

  2. Extend sendFileWithContent() to handle custom content length in basebackup.c