From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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 18:44:26 |
Message-ID: | CA+TgmoYo1Gu5+0xy7-ivmjsdDfCPDPyyV+yL66XjMeOwTCEAFA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 20, 2023 at 12:54 PM David Steele <david(at)pgmasters(dot)net> wrote:
> Another thing we could do is explicitly error if we see backup_label in
> PGDATA during recovery. That's just a few lines of code so would not be
> a big deal to maintain. This error would only be visible on restore, so
> it presumes that backup software is being tested.
I think that if we do decide to adopt this proposal, that would be a
smart precaution.
> A little hard to add to the tests, I think, since they are purely
> informational, i.e. not pushed up by the parser. Maybe we could just
> grep for the fields?
Hmm. Or should they be pushed up by the parser?
> I think these fields would be handled the same as the rest of the fields
> in backup_label: returned from pg_backup_stop() and also stored in
> backup_manifest. Third-party software can do as they like with them and
> pg_combinebackup can just read from backup_manifest.
I think that would be a bad plan, because this is critical
information, and a backup manifest is not a thing that you're required
to have. It's not a natural fit at all. We don't want to create a
situation where if you nuke the backup_manifest then the server
forgets that what it has is an incremental backup rather than a usable
data directory.
> We absolutely need more people to look at this and sign off. I'm glad
> they have not so far because it has allowed time to whack the patch
> around and get it into better shape.
Cool.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jubilee Young | 2023-11-20 18:50:36 | Re: Hide exposed impl detail of wchar.c |
Previous Message | Andres Freund | 2023-11-20 18:36:33 | Re: Use of backup_label not noted in log |