On Mon, Sep 14, 2026 at 5:59 PM Daniel Gustafsson <[email protected]> wrote: > Once the cluster has moved to inprogress-on, any new orphan files will have > checksums written. This means that if the launcher can get a list of orphan > files once the state has changed, there cannot be any more created (without > checksums) during processing. There can still be new orphan files *with* > checksums written, but those would be no different from what we have today > with > pg_checksums processing.
That's a very good point. One thing that bothers me is: why don't we just process the files by directory scan to begin with, instead of trying to get at them via pg_class and then using this mechanism to mop up the leftovers? I suspect the answer is locking. For an actually orphaned file, we don't need to lock anything. But it might be hard to tell the difference between a file that corresponds to nothing we saw in pg_class because it's orphaned and a file that corresponds to nothing we saw in pg_class because it was concurrently created and the pg_class entry isn't yet visible to us. And, in the latter case, skipping locking would probably be bad for all the same reasons it would be bad to do that in general. But if you can find some way to distinguish those cases reliably, then I think this might be a robust fix. -- Robert Haas
