Re: Return pg_control from pg_backup_stop().
David Steele <david@pgbackrest.org>
From: David Steele <david@pgbackrest.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-20T22:44:36Z
Lists: pgsql-hackers
Attachments
- pgcontrol-flag-v4-02-sql.patch (text/plain) patch v4
- pgcontrol-flag-v4-01-basebackup.patch (text/plain) patch v4
On 10/3/24 05:11, David Steele wrote: > On 10/3/24 07:45, Michael Paquier wrote: > >> 1) is something that has more value than 2), IMO, because there is no >> need for a manual step when a backup is taken by the replication >> protocol. Well, custom backup solutions that rely on the replication >> protocol to copy the data would need to make sure that they have a >> backup_label, but that's something they should do anyway and what this >> patch wants to protect users from. The SQL part is optional IMO. It >> can be done, but it has less impact overall and makes backups more >> complicated by requiring the manual copy of the control file. > > I don't think having incremental backup in pg_basebackup means alternate > backup solutions are going away or that we should deprecate the SQL > interface. If nothing else, third-party solutions need a way to get an > untorn copy of pg_control and in general I think the new flag will be > universally useful. I updated this patch to fix an issue with -fsanitize=alignment. I'm not entirely happy with copying twice but not sure of another way to do it. As far as I can see VARDATA() will not return aligned data on 64-bit architectures. Regards, -David