From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add recovery to pg_control and remove backup_label |
Date: | 2023-11-05 17:30:07 |
Message-ID: | aea499f7-06cc-43fe-9a89-58402bf12d52@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2023-11-05 17:45:39 | Re: Add recovery to pg_control and remove backup_label |
Previous Message | Dean Rasheed | 2023-11-05 11:52:09 | Re: MERGE ... RETURNING |