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

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