On 7/8/22 09:10, Christoph Berg wrote:
> Re: David Steele
>>> 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
>
> I was just wondering: Why is "labelfile" only returned by
> pg_backup_stop()? All the info in there is already available at
> pg_backup_start() time.
Not sure exactly why this decision was made in 9.6 (might be because
tablespace_map does need to be generated at stop time), but I'm planning
to add data to this file in PG16 that is only available at stop time. In
particular, backup software would like to know the earliest possible
time that can be used for PITR and right now this needs to be
approximated. Would be good to have that in backup_label along with
start time. Min recovery xid would also be very useful.
> Having the output available earlier would
> allow writing the backup_label into the backup directory, or store it
> along some filesystem snapshot that is already immutable by the time
> pg_backup_stop is called.
What is precluded by getting the backup label after pg_backup_stop()?
Perhaps a more detailed example here would be helpful.
> If we rename all functions anyway for PG15, we could move the info
> from stop to start.
>
>> 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.
>
> Is that really an argument for making the life of everyone else
> harder?
I don't see how anyone's life is made harder unless the plan is to write
backup_label into PGDATA, which should not be done.
As we've noted before, there's no point in pretending that doing backup
correctly is easy because it is definitely not.
Regards,
-David