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

On Mon, Oct 26, 2026 at 12:21 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> I'd suggest to wait a bit for Robert a bit in case he'd like to
> comment on the file size expectation of the on-disk stash advice file.
> Saying that, could you adjust the 2PC file? I'd just fix that now and
> be done with it..

I don't think we should be too fussed about cases like this.
Generally, the reason we rename files into place instead of just
overwriting random bytes is so that readers will see either the old or
the new version, and not some mix of old and new contents. David's
original report surfaces a case where that doesn't happen: we might
take the length of one file and then use it for a completely different
file that is meanwhile renamed into place. Fixing that makes renaming
into place work the way writers already expect it to work. I don't see
why we need to do better. If there are other cases where
rename-into-place doesn't work, I'd tend to favor trying to cut those
problems off at the source rather than complicating file formats.

Now, that's not to say that having some kind of end-of-file marker is
completely without merit. It could catch manual modifications of
files, hardware problems, software errors -- generally, failure modes
that we otherwise wouldn't notice. On the other hand, isn't it kind of
nice that the stash file format is just a plain old TSV that anyone
can edit if they so desire? I judge that to have non-zero value, and
if we add checksums or end-of-file markers or other frammishes, we
lose that property, obviously to varying degrees depending on what
exactly we do.

--
Robert Haas
Databricks