Re: Add recovery to pg_control and remove backup_label
| От | David G. Johnston |
|---|---|
| Тема | Re: Add recovery to pg_control and remove backup_label |
| Дата | |
| Msg-id | CAKFQuwbBMP6sP5zMairXjzx-7eXhbG+d6Etm4CceqOjTXJnGoQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add recovery to pg_control and remove backup_label (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Add recovery to pg_control and remove backup_label
|
| Список | 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.
В списке pgsql-hackers по дате отправления: