Re: Add function to return backup_label and tablespace_map

On 7/8/22 07:53, Bharath Rupireddy wrote:
> 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.

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