Re: Add recovery to pg_control and remove backup_label
David Steele <david@pgmasters.net>
From: David Steele <david@pgmasters.net>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2023-11-05T17:30:07Z
Lists: pgsql-hackers
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
Commits
-
Doc: improve documentation for jsonpath behavior.
- 7014c9a4bba2 17.0 cited
-
Extend sendFileWithContent() to handle custom content length in basebackup.c
- 7606175991f8 17.0 landed