Re: Return pg_control from pg_backup_stop().
| От | David Steele |
|---|---|
| Тема | Re: Return pg_control from pg_backup_stop(). |
| Дата | |
| Msg-id | feb68313-3257-4d9d-8b69-6468e506a61a@pgbackrest.org обсуждение исходный текст |
| Ответ на | Re: Return pg_control from pg_backup_stop(). (Haibo Yan <tristan.yim@gmail.com>) |
| Ответы |
Re: Return pg_control from pg_backup_stop().
|
| Список | 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
В списке pgsql-hackers по дате отправления: