Re: Add function to return backup_label and tablespace_map

On Fri, Jul 8, 2022 at 5:12 PM David Steele <david@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.

Also, do we need the read_backup_label part of the code [1]?


[1]
    if (read_backup_label(&CheckPointLoc, &CheckPointTLI, &backupEndRequired,
                          &backupFromStandby))
    {
        List       *tablespaces = NIL;

        /*
         * Archive recovery was requested, and thanks to the backup label
         * file, we know how far we need to replay to reach consistency. Enter
         * archive recovery directly.
         */
        InArchiveRecovery = true;
        if (StandbyModeRequested)
            StandbyMode = true;

        /*
         * When a backup_label file is present, we want to roll forward from
         * the checkpoint it identifies, rather than using pg_control.
         */

Regards,
Bharath Rupireddy.