Re: Add recovery to pg_control and remove backup_label

On Fri, Oct 27, 2023 at 7:10 AM David Steele <david(at)pgmasters(dot)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.