Re: Trying to break online checksums with LLMs

> On 14 Sep 2026, at 21:59, Robert Haas <robertmhaas(at)gmail(dot)com> 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