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
