On Thu, Sep 3, 2026 at 9:49 AM Jacob Champion
<jacob.champion@enterprisedb.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
wantme 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.
Or we could decide that the existing behavior is what we want, and
adjust the following comment in pg_checksums.c to no longer refer to a
dead implementation:
> /*
> * List of files excluded from checksum validation.
> *
> * Note: this list should be kept in sync with what basebackup.c includes.
> */
and probably adjust this code so that it doesn't always print "segment
number 0", which isn't derived from the filename:
> segmentno = atoi(segmentpath);
> if (segmentno == 0)
> pg_fatal("invalid segment number %d in file name \"%s\"",
> segmentno, fn);
Or something else entirely. Thoughts?
Thanks,
--Jacob
[1] https://postgr.es/c/025584a16
