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

> On 3 Sep 2026, at 19:10, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> On Thu, Sep 3, 2026 at 9:49 AM Jacob Champion
> <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>>> I will file a bug report for this issue in github for the third-party extension pgactive. Please let me know if you want me to report an enhancement request or thet you take care about that
>>
>> I'm happy to shepherd the conversation over to -hackers, and will do
>> that shortly. (I'm probably not the right person to drive it.)
>
> Moving to -hackers.
>
> I can't remember the last conversation I saw on dealing with
> third-party files in our data directory, sorry. Occasionally we're
> fine with them, and occasionally we try to parse apart their filenames
> and fail during checksum operations. I don't think that's a bug, but
> an actionable complaint from the bug report is that PG17 relaxed this
> requirement for pg_basebackup [1] and not pg_checksums, which is kind
> of weird.
>
> The inciting event is that an extension drops a file called
> pgactive.stat into global/. We could say "don't do that", in which
> case I think we should follow Robert's idea in [1] and complain about
> the existence of the file itself rather than the lack of checksummable
> material. Or we could say "that's fine" and adjust pg_checksums to
> continue onwards if the filename isn't what we expect.

I'm not sure I have a strong preference, keeping it in sync with pg_basebackup
seems like a pretty good strategy to make it easier for users.

pg_checksums won't be immune to false negatives even with this as it will still
be able to read stale leftover datafiles from crashed DROP commands.

--
Daniel Gustafsson