> On 3 Sep 2026, at 19:10, Jacob Champion <[email protected]> > wrote: > > On Thu, Sep 3, 2026 at 9:49 AM Jacob Champion > <[email protected]> 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
