> On 14 Sep 2026, at 21:59, Robert Haas <[email protected]> wrote:
> It's for the RMT to decide whether that's good enough, but I'm > skeptical. I think a big part of the problem here is that it's really > hard to make something race-free. 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. This reduction in problem scope likely means we can avoid the race conditions that such scans are usually subject to. This is back-of-napkin sketching but I think this invariant of the orphan files problem is less hard than the generic one. But at any rate, this is clearly not the time to design that. If we revert we should keep online checksums in master and only pull it out of 19, to allow for this to be fixed early in 20, and avoid the churn. I held off from backpatching the open item fix for this very reason; unless I hear otherwise by Wednesday I'll go ahead with the revert, else the backpatch. Adding RMT to the thread to keep everyone in the loop. -- Daniel Gustafsson
