Re: Trying to break online checksums with LLMs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Trying to break online checksums with LLMs
Date: 2026-09-10 20:37:15
Message-ID: 927668.1789072635@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-09-10 20:48:22 Re: First draft of PG 19 release notes
Previous Message Mario Karuza 2026-09-10 20:36:01 tuplesort_putdatum() does not account for tuple memory