Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

On Thu, 30 Oct 2025 at 19:40, David E. Wheeler <david(at)justatheory(dot)com> wrote:
>
> On Oct 30, 2025, at 09:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Trouble is, you then need an arbitrary client-made choice about which
> > commit to run the ABI check against.
>
> It’s currently coded to use the most recent tag or, if there is none in the branch, the branch root.

Yes, like before the addition of .abi-compliance-history in the
REL_18_STABLE branch, REL_18_0 was being used as the baseline.

> > If that code does something we
> > realize we don't want, we're back up against the problem of moving the
> > buildfarm configuration to fix it. I'd rather the decision be opt-in.

No changes to individual animal configurations will be required. Once
a STABLE branch gets the .abi-compliance-history file, the baseline
will update automatically from the lastest tag to the mentioned commit
SHA for all clients. :D

> Fair. Just means that if no one adds a history file to a branch that branch will never be tested and there’s no automated way to realize it.

Although I don’t oppose the idea of “don’t run the ABI check unless
the branch has a .abi-compliance-history file”, it would just need
some minor code removals and adjustments.
We can put a note in the compliance check result for new STABLE
branches - "no .abi-compliance-history file found", but keep the
client status green?