| From: | David Steele <david(at)pgmasters(dot)net> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add recovery to pg_control and remove backup_label |
| Date: | 2023-11-20 19:56:19 |
| Message-ID: | 75071637-6b5c-483b-ac55-9c15b69eaca0@pgmasters.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/20/23 15:47, Robert Haas wrote:
> On Mon, Nov 20, 2023 at 2:41 PM David Steele <david(at)pgmasters(dot)net> wrote:
>> I can't see why a backup would continue to be valid without a manifest
>> -- that's not very standard for backup software. If you have the
>> critical info in backup_label, you can't afford to lose that, so why
>> should backup_manifest be any different?
>
> I mean, you can run pg_basebackup --no-manifest.
Maybe this would be a good thing to disable for page incremental. With
all the work being done by pg_combinebackup, it seems like it would be a
good idea to be able to verify the final result?
I understand this is an option -- but does it need to be? What is the
benefit of excluding the manifest?
Regards,
-David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-11-20 20:01:09 | Re: Annoying build warnings from latest Apple toolchain |
| Previous Message | Matthias van de Meent | 2023-11-20 19:48:39 | Re: Parallel CREATE INDEX for BRIN indexes |