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

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. 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.

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.
--
Michael