Re: Return pg_control from pg_backup_stop(). - Mailing list pgsql-hackers

From Haibo Yan
Subject Re: Return pg_control from pg_backup_stop().
Date
Msg-id 7F7B289B-F94F-42C2-9E54-6A689C0D64BB@gmail.com
Whole thread Raw
In response to Re: Return pg_control from pg_backup_stop().  (David Steele <david@pgbackrest.org>)
List pgsql-hackers
Hi David,

Thank you for the clarification. I have now read the code, and overall it looks good to me. I only had one very small comment.

You currently have:
```
memset(controlFile + sizeof(ControlFileData), 0,
       PG_CONTROL_FILE_SIZE - sizeof(ControlFileData));
memcpy(controlFile, ControlFile, sizeof(ControlFileData));
``` 
This is correct, since only the trailing bytes need to be zeroed before the copy.

I was just wondering whether the following might be slightly clearer:
```
memset(controlFile, 0, PG_CONTROL_FILE_SIZE);
memcpy(controlFile, ControlFile, sizeof(ControlFileData));
```

I do not think this is a real issue, though.

Thanks
Haibo

On Mar 17, 2026, at 12:05 AM, David Steele <david@pgbackrest.org> wrote:

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 by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Speed up COPY TO text/CSV parsing using SIMD
Next
From: Andrew Dunstan
Date:
Subject: Re: IS JSON predicate support for domain base type as JSON/JSONB/BYTEA/TEXT