Re: Return pg_control from pg_backup_stop().

On 11/20/24 17:44, David Steele wrote:
> 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.

Rebased and improved a comment and an error.

Regards,
-David