From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Daniel Gustafsson <daniel@yesql.se>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Trying to break online checksums with LLMs
In-reply-to: 
 <CA+TgmoaOCdjAjr240e_+xoqQCRmLC9MFn3kZOu-7j8w8HBrd8g@mail.gmail.com>
References: <E15AC050-C4B5-488D-BB2D-3C7AC9F89EA8@yesql.se>
 <CA+TgmoaOCdjAjr240e_+xoqQCRmLC9MFn3kZOu-7j8w8HBrd8g@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Thu, 10 Sep 2026 16:33:21 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <927667.1789072635.1@sss.pgh.pa.us>
Date: Thu, 10 Sep 2026 16:37:15 -0400
Message-ID: <927668.1789072635@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/927668.1789072635%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> But much more seriously, Claude also noticed this: In general, if
> PostgreSQL creates a relation and then crashes before commit, the
> relation files are left on disk and not removed, but there's no
> catalog entry pointing to them any more. If checksums are enabled
> using pg_checksums, such files are updated to have checksums as well.
> But this feature enables checksums by working through the catalog, so
> it won't update those files. That means that if, at any point in the
> history of the cluster, there's ever been a crash that left a relation
> file behind on disk, and then you use this feature to enable
> checksums, and then after that you take a base backup, checksum
> verification will fail, and thus the backup will fail. I don't quite
> see how we can actually fix this, and it seems like a serious problem.

Don't we have logic somewhere to clean up orphaned relation files?

			regards, tom lane