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
-
Doc: improve documentation for jsonpath behavior.
- 7014c9a4bba2 17.0 cited
-
Extend sendFileWithContent() to handle custom content length in basebackup.c
- 7606175991f8 17.0 landed