Subject: Re: abi-compliance-checker

From: Alvaro Herrera <[email-masked]>
Date: Tue, 27 Feb 2024 14:25:46 +0100

On 2023-Nov-01, Peter Eisentraut wrote:

> v3-0001-abidw-option.patch
> 
> This adds the abidw meson option, which produces the xml files with the ABI
> description.  With that, you can then implement a variety of workflows, such
> as the abidiff proposed in the later patches, or something rigged up via CI,
> or you can just build various versions locally and compare them.  With this
> patch, you get the files to compare built automatically and don't have to
> remember to cover all the libraries or which options to use.
> 
> I think this patch is mostly pretty straightforward and agreeable, subject
> to technical review in detail.

I like this idea and I think we should integrate it with the objective
of it becoming the workhorse of ABI-stability testing.  However, I do
not think that the subsequent patches should be part of the tree at all;
certainly not the produced .xml files in your 0004, as that would be far
too unstable and would cause a lot of pointless churn.

> TODO: documentation

Yes, please.

> TODO: Do we want a configure/make variant of this?

Not needed IMO.

The way I see this working, is that we set up a buildfarm animal [per
architecture] that runs the new rules produced by the abidw option and
stores the result locally, so that for stable branches it can turn red
when an ABI-breaking change with the previous minor release of the same
branch is introduced.  There's no point on it ever turning red in the
master branch, since we're obviously not concerned with ABI changes there.

(Perhaps we do need 0003 as an easy mechanism to run the comparison, but
I'm not sure to what extent that would be actually helpful.)

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

---

From: Peter Geoghegan <[email-masked]>
Date: Tue, 27 Feb 2024 08:45:12 -0500

> master branch, since we're obviously not concerned with ABI changes there.

ABI stability doesn't seem like something that you can alert on. There
are quite a few individual cases where the ABI was technically broken,
in a way that these tools will complain about. And yet it was
generally understood that these changes did not really break ABI
stability, for various high-context reasons that no tool can possibly
be expected to understand. This will at least be true under our
existing practices, or anything like them.

For example, if you look at the "Problems with Symbols, High Severity"
from the report I posted comparing REL_11_0 to REL_11_20, you'll see
that I removed _bt_pagedel() when backpatching a fix. That was
justified by the fact that any extension that was calling that
function was already hopelessly broken (I pointed this out at the
time).

Having some tooling in this area would be extremely useful. The
absolute number of false positives seems quite manageable, but the
fact is that most individual complaints that the tooling makes are
false positives. At least in some deeper sense.

-- 
Peter Geoghegan