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