| From: | David Steele <david(at)pgbackrest(dot)org> |
|---|---|
| To: | Haibo Yan <tristan(dot)yim(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Return pg_control from pg_backup_stop(). |
| Date: | 2026-03-17 07:05:06 |
| Message-ID: | feb68313-3257-4d9d-8b69-6468e506a61a@pgbackrest.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/17/26 12:16, Haibo Yan wrote:
> I have not read the code yet, so this may already be answered there, but
> I had a question about the proposal itself. This patch protects against
> a missing backup_label, but what about a wrong one? If a user restores a
> backup_label file from a different backup, the existence check alone
> would not detect that. Do we need some consistency check between the
> returned pg_control copy and the backup_label contents, or is the
> intended scope here limited to the “missing file” case only?
Thank you for having a look!
The goal here is only to check for a missing backup_label. The general
problem is that PostgreSQL suggests that removing backup_label might be
a good idea so the user does it:
If you are not restoring from a backup, try removing the file
\"%s/backup_label\"
The user *could* copy a backup_label from another backup and there are
ways we could detect that but I feel that should be material for a
separate patch.
Regards,
-David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kirill Reshke | 2026-03-17 07:19:31 | Re: SQL Property Graph Queries (SQL/PGQ) |
| Previous Message | Pavel Stehule | 2026-03-17 06:58:20 | Re: POC: PLpgSQL FOREACH IN JSON ARRAY |