From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, David Steele <david(at)pgmasters(dot)net>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add recovery to pg_control and remove backup_label |
Date: | 2023-11-20 21:18:15 |
Message-ID: | CAKFQuwbBMP6sP5zMairXjzx-7eXhbG+d6Etm4CceqOjTXJnGoQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 20, 2023 at 1:37 PM Andres Freund <andres(at)anarazel(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-11-20 21:20:20 | Re: Annoying build warnings from latest Apple toolchain |
Previous Message | Robert Haas | 2023-11-20 20:57:40 | Re: Annoying build warnings from latest Apple toolchain |