Re: Trying to break online checksums with LLMs

On Mon, Sep 14, 2026 at 5:59 PM Daniel Gustafsson <daniel(at)yesql(dot)se> 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