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 <[email protected]> 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
>
>