On Fri, Jul 8, 2022 at 3:31 PM Bharath Rupireddy
<bharath.rupireddyforpostg...@gmail.com> wrote:
>
> On Thu, Jul 7, 2022 at 10:14 PM Fujii Masao <masao.fu...@oss.nttdata.com>
> wrote:
> >
> > Hi,
> >
> > Since an exclusive backup method was dropped in v15, in v15 or later, we
> > need to create backup_label and tablespace_map files from the result of
> > pg_backup_stop() when taking a base backup using low level backup API. One
> > issue when doing this is that; there is no simple way to create those files
> > from two columns "labelfile" and "spcmapfile" that pg_backup_stop() returns
> > if we execute it via psql. Probaby we need to store those columns in a
> > temporary file and run some OS commands or script to separate that file
> > into backup_label and tablespace_map. This is not simple way, and which
> > would prevent users from migrating their backup scripts using psql from an
> > exclusive backup method to non-exclusive one, I'm afraid.
> >
> > 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, also even
> > after pg_backup_stop() finishes. For example, this function allows us to
> > take a backup using the following psql script file.
> >
> > ------------------------------
> > SELECT * FROM pg_backup_start('test');
> > \! cp -a $PGDATA /backup
> > SELECT * FROM pg_backup_stop();
> >
> > \pset tuples_only on
> > \pset format unaligned
> >
> > \o /backup/data/backup_label
> > SELECT labelfile FROM pg_backup_label();
> >
> > \o /backup/data/tablespace_map
> > SELECT spcmapfile FROM pg_backup_label();
> > ------------------------------
> >
> > Attached is the WIP patch to add pg_backup_label function. No tests nor
> > docs have been added yet, but if we can successfully reach the consensus
> > for adding the function, I will update the patch.
> >
> > Thought?
>
> +1 for making it easy for the user to create backup_label and
> tablespace_map files. With the patch, the label_file and
> tblspc_map_file contents are preserved until the lifecycle of the
> session or the next run of pg_backup_start, I'm not sure if we need to
> worry more about it.
>
> Why can't we have functions like pg_create_backup_label() and
> pg_create_tablespace_map() which create the 'backup_label' and
> 'tablespace_map' files respectively in the data directory and also
> return the contents as output columns?
>
> Also, we can let users run these create functions only once (perhaps
> after the pg_backup_stop is called which is when the contents will be
> consistent). If we allow these functions to read the label_file or
> tblspc_map_file contents during the backup before stop backup, they
> may not be consistent. We can have a new sessionBackupState something
> like SESSION_BACKUP_READY_TO_COLLECT_INFO or SESSION_BACKUP_DONE and
> after the new function calls sessionBackupState goes to
> SESSION_BACKUP_NONE) and the contents of label_file and
> tblspc_map_file are freed up.
>
> In the docs, it's good if we can clearly specify the steps to use all
> of these functions.
Forgot to mention a comment on the v1 patch: we'll need to revoke
permissions from the public for pg_backup_label (or whatever the new
function(s) that'll be introduced) as well similar to pg_backup_start
and pg_backup_stop.
Regards,
Bharath Rupireddy.
