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