Re: Avoid truncated or zero-padded copies of replaced files in backups.

On 10/27/26 06:02, Michael Paquier wrote:
> On Mon, Oct 26, 2026 at 10:36:30AM +0000, David Steele wrote:
>> My hope is that all the eyeballs have caught the only problematic case (2pc)
>> but we'll need to be careful when adding new files in the future. If all the
>> examples in the code are correct it should be easier to get it right.
>
> I would bet a coin that somebody will include in the core code files
> that break this rule at some future point.

There is no way I am taking that bet.

> Perhaps we should be more
> aggressive in terms of in-core backend sanity checks. I am not sure
> what these would look like, though, and I doubt that such a thing
> would be worth the long-term maintenance cost vs the number of issues
> avoided.

Hopefully having correct examples to copy from will help, otherwise this
is the purpose of review. I can't think of any way to fool-proof it.

> The backpatches for v15 and v16 were not that complicated, as you said
> I have just used a boolean to track if we are working on a relation
> file or not and expanded sendFile() with one argument. One thing that
> I have left out of the picture is v14. It is going to be EOL with the
> next round of minors, and the races are edgy enough that I did not see
> this branch as worth taking a risk.
Agreed, my worry on putting anything like this into the soon-to-be-EOL
release is that if we get it wrong that's a net negative for that release.

I don't know of any instances of this race actually happening in the
wild, and since pgBackRest has never had the issue I don't have any data
from that side.

Thank you for reviewing and committing!

Regards,
-David