| 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: | Whole Thread | Raw Message | 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 |