On 7/8/22 07:53, Bharath Rupireddy wrote:
On Fri, Jul 8, 2022 at 5:12 PM David Steele <da...@pgmasters.net> wrote:
To enable us to do that more easily, how about adding the
pg_backup_label() function that returns backup_label and tablespace_map?
I'm thinking to make this function available just after
pg_backup_start() finishes
This makes me nervous as I'm sure users will immediately start writing
backup_label into PGDATA to make their lives easier. Having backup_label
in PGDATA for a running cluster causes problems and is the major reason
we deprecated and then removed the exclusive method. In addition, what
little protection we had from this condition has been removed.
IIUC, with the new mechanism, we don't need a backup_label file to be
present in the data directory after pg_backup_stop? If yes, where will
the postgres recover from if it crashes after pg_backup_stop before
the next checkpoint? I'm trying to understand the significance of the
backup_label and tablespace_map contents after the removal of
exclusive backup.
backup_label should be written directly into the backup and should be
present when the backup is restored and before recovery begins. It
should not be present in a normally operating cluster or it will cause
problems after crashes and restarts.
Also, do we need the read_backup_label part of the code [1]?
Yes, since the backup_label is required for recovery.
Regards,
-David
