Re: Return pg_control from pg_backup_stop().

From: David Steele <david(at)pgbackrest(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Return pg_control from pg_backup_stop().
Date: 2024-11-20 22:44:36
Message-ID: fe9a5423-c36d-43ad-9884-dee4c3b7dc6d@pgbackrest.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
pgcontrol-flag-v4-02-sql.patch text/plain 11.4 KB
pgcontrol-flag-v4-01-basebackup.patch text/plain 11.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-11-20 22:47:37 Re: Accessing other session's temp table
Previous Message Mark Dilger 2024-11-20 22:25:37 Re: cannot freeze committed xmax