Re: Do we want to avoid checksumming extra files in the datadir? [was: BUG #19647] - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Do we want to avoid checksumming extra files in the datadir? [was: BUG #19647]
Date
Msg-id CAOYmi+mMy4RFVcicTiHj6Yqkj=0_E6uAHR56NwgZXWc9tcDT7A@mail.gmail.com
Whole thread
In response to Do we want to avoid checksumming extra files in the datadir? [was: BUG #19647]  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
On Thu, Sep 3, 2026 at 11:30 AM Jacob Champion
<jacob.champion@enterprisedb.com> 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

Attachment

pgsql-hackers by date:

Previous
From: surya poondla
Date:
Subject: Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon
Next
From: Ilia Evdokimov
Date:
Subject: Re: Apply extended statistics to join clause during parameterized path costing