Re: Add recovery to pg_control and remove backup_label
От
David Steele
Тема
Re: Add recovery to pg_control and remove backup_label
Дата
Msg-id
aea499f7-06cc-43fe-9a89-58402bf12d52@pgmasters.net
Ответ на
Re: Add recovery to pg_control and remove backup_label (David G. Johnston)
Список
Дерево обсуждения
Add recovery to pg_control and remove backup_label David Steele <david@pgmasters.net>
Re: Add recovery to pg_control and remove backup_label David Steele <david@pgmasters.net>
Re: Add recovery to pg_control and remove backup_label Michael Paquier <michael@paquier.xyz>
Re: Add recovery to pg_control and remove backup_label David Steele <david@pgmasters.net>
Re: Add recovery to pg_control and remove backup_label Michael Paquier <michael@paquier.xyz>
Re: Add recovery to pg_control and remove backup_label Michael Paquier <michael@paquier.xyz>
Re: Add recovery to pg_control and remove backup_label David Steele <david@pgmasters.net>
Re: Add recovery to pg_control and remove backup_label Michael Paquier <michael@paquier.xyz>
Re: Add recovery to pg_control and remove backup_label "David G. Johnston" <david.g.johnston@gmail.com>
Re: Add recovery to pg_control and remove backup_label David Steele <david@pgmasters.net>
Re: Add recovery to pg_control and remove backup_label "David G. Johnston" <david.g.johnston@gmail.com>
Re: Add recovery to pg_control and remove backup_label David Steele <david@pgmasters.net>
Re: Add recovery to pg_control and remove backup_label Michael Paquier <michael@paquier.xyz>
Re: Add recovery to pg_control and remove backup_label David Steele <david@pgmasters.net>
On 10/27/23 13:45, David G. Johnston wrote: > > Let me modify that to make it a bit more clear, I actually wouldn't care > if pg_backup_end outputs an entire binary pg_control file as part of the > SQL resultset. > > My proposal would be to, in addition, place in the temporary directory > on the server, Postgres-written versions of pg_control and > tablespace_map as part of the pg_backup_end processing. The client > software would then have a choice. Write the contents of the SQL > resultset to newly created binary mode files in the destination, or, > copy the server-written files from the temporary directory to the > destination. > > That said, I'm starting to dislike that idea myself. It only really > makes sense if the files could be placed in the data directory but that > isn't doable given concurrent backups and not wanting to place the > source server into an inconsistent state. Pretty much the conclusion I have come to myself over the years. Regards, -David
В списке pgsql-hackers по дате отправления