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

On Oct 29, 2025, at 22:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

>> We can remove the branch check, of course, but then you would have to maintain .abi-compliance-history in master, no?
>
> No; my proposal was "don't run the ABI check unless the branch has
> a .abi-compliance-history file". master would normally not contain
> such a file, thus no check. As I was just discussing with Bruce,
> we could put one there for awhile if we wanted to run ABI checks in
> advance of forking a stable branch.

Oh, I see, that’s certainly do-able.

> The reason I'm so allergic to having any of these decisions made on
> the buildfarm-client side is years of herding cats^W^W trying to get
> buildfarm owners to update their script versions and/or config files.
> It's close to hopeless. Thus, your proposal a message or three back
> to add another BF client config setting to control this sounds like
> the worst of all possible worlds. If we needed a change in the
> setting, getting the farm to converge to that would take months if not
> years. The idea that we could transiently enable checks between beta1
> and branch fork on the basis of that approach is downright risible.
> On the other hand, if the decisions are driven purely by what is in
> our git tree, a change is the work of moments.

That makes excellent sense, I appreciate the context.

Might I suggest, however, that it also run for branches matching /_STABLE$/ even if there is no .abi-hstory-file? The whole point of this exercise was to increase the confidence in ABI stability in stable branches. Running it in such branches would help remind maintainers to add the file.

OTOH, if someone ran it for really old branches it could bs super annoying, so maybe not…

D