Re: Add function to return backup_label and tablespace_map

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: Add function to return backup_label and tablespace_map
Дата
Msg-id 9f656d95-9fc7-3f33-bec7-1048cf780a32@pgmasters.net
обсуждение исходный текст
Ответ на Add function to return backup_label and tablespace_map  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: Add function to return backup_label and tablespace_map  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Re: Add function to return backup_label and tablespace_map  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Add function to return backup_label and tablespace_map  (Christoph Berg <myon@debian.org>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Add function to return backup_label and tablespace_map