On Mon, Oct 26, 2026 at 12:21 AM Michael Paquier <[email protected]> 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
