Re: Add function to return backup_label and tablespace_map

From: Christoph Berg <myon(at)debian(dot)org>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)postgresql(dot)org, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Add function to return backup_label and tablespace_map
Date: 2022-07-08 13:10:46
Message-ID: Ysgs1njP5uFVF95H@msg.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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.

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?

Christoph

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-07-08 13:43:22 Re: Patch proposal: New hooks in the connection path
Previous Message David Steele 2022-07-08 13:09:27 Re: Add function to return backup_label and tablespace_map