From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | 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 11:41:52 |
Message-ID: | 9f656d95-9fc7-3f33-bec7-1048cf780a32@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/7/22 12:43, Fujii Masao wrote:
> 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.
Why not just select these columns into a temp table:
create temp table backup_result as select * from pg_backup_stop(...);
Then they can be easily dumped with \o by selecting from the temp table.
> 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
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.
Regards,
-David
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2022-07-08 11:53:17 | Re: Add function to return backup_label and tablespace_map |
Previous Message | Masahiko Sawada | 2022-07-08 11:20:51 | Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns |