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 |
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 |