Re: Add recovery to pg_control and remove backup_label - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Add recovery to pg_control and remove backup_label
Date
Msg-id CAKFQuwbn3rvA7o-=Sbn93mo9MJPDmExBWYa5Lph51hyZWtj13w@mail.gmail.com
Whole thread Raw
In response to Re: Add recovery to pg_control and remove backup_label  (David Steele <david@pgmasters.net>)
Responses Re: Add recovery to pg_control and remove backup_label
List pgsql-hackers
On Fri, Oct 27, 2023 at 7:10 AM David Steele <david@pgmasters.net> wrote:
On 10/26/23 17:27, David G. Johnston wrote:

> Can we not figure out some way to place the relevant files onto the
> server somewhere so that a simple "cp" command would work?  Have
> pg_backup_stop return paths instead of contents, those paths being
> "$TEMP_DIR"/<random unique new directory>/pg_control.conf (and
> tablespace_map)

Nobody has been able to figure this out, and some of us have been
thinking about it for years. It just doesn't seem possible to reliably
tell the difference between a cluster that was copied and one that
simply crashed.

If cp is really the backup tool being employed, I would recommend using
pg_basebackup. cp has flaws that could lead to corruption, and of course
does not at all take into account the archive required to make a backup
consistent, directories to be excluded, the order of copying pg_control
on backup from standy, etc., etc.


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.

David J.

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: BRIN minmax multi - incorrect distance for infinite timestamp/date
Next
From: Tom Lane
Date:
Subject: Re: Enderbury Island disappeared from timezone database