Hi Jacob, all,

I applied v2-0001..0003 on top of master (e40b509c08) and tested them.

- pg_checksums (77 tests) and pg_basebackup (352 tests) TAP tests pass.
- With stray files in global/ ("foreign_file" with 4 bytes and
  "foreign.conf"), unpatched pg_checksums fails ("could not read block
  0 ... read 4 of 8192"; the dotted name gave "invalid segment number
  0"), while v2 exits 0.
- On a cluster with a table, an index and an unlogged table, patched
  and unpatched report identical counts (956 files, 9362 blocks).
- "--filenode 0" is rejected with "must be in range 1..2147483647".

Two things I noticed while reviewing:

1. doc/src/sgml/ref/pg_checksums.sgml still says that when verifying
   checksums "every file in the cluster is scanned". With 0003 that is
   no longer accurate; it could say "every relation file" and mention
   that other files are ignored.

2. Per Rui's review, the 0003 commit message could mention that
   --filenode is now compared numerically, and a leading-zero
   --filenode case is not yet in check_relation_corruption().

I'm happy to write the docs and test changes if you'd like.

Thanks,
Shubhra




On Wed, Oct 7, 2026 at 4:32 PM Jacob Champion <
[email protected]> wrote:

> On Thu, Sep 3, 2026 at 11:30 AM Jacob Champion
> <[email protected]> wrote:
> > Sounds good, thanks both! Attached is the simplest thing that could
> > fix the reported problem (and nothing else), but I'd rather look into
> > moving parse_filename_for_nontemp_relation() to common/relfile.c so it
> > can be used directly. I probably won't have time for that today.
>
> Here's a v2 to do that, which I like much better.
>
> The --filenode argument now filters via integer equality rather than a
> string comparison. I think there are two main side effects (let me
> know if either is unacceptable):
> 1) we now prohibit `pg_checksums --filenode 0`, which IIUC isn't ever
> helpful in practice, and
> 2) leading zeroes in the --filenode arg are now ignored, rather than
> causing pg_checksums to match nothing. I.e. `--filenode 001260` will
> now match relfile 1260.
>
> Are there are any corner cases I've missed where you want pg_checksums
> to check a temporary relation's relfiles? Even if a clean shutdown and
> startup somehow left them around, they still wouldn't be used, right?
>
> Thanks,
> --Jacob
>

Reply via email to