On 2025-Sep-12, Tom Lane wrote:
> My concern is that when we get a report, we might decide to apply
> some fix to remove the ABI delta, or we might decide it's intentional
> and/or harmless and leave the code as-is. In the latter case, the
> ABI-checking BF animal(s) will be red until the next release is made,
> which helps nobody, particularly because it will probably interfere
> with noticing any ABI breaks in later commits.
The solution I propose for this (which I have mentioned before) is to
allow for our source tree to carry exclusion files. The ABI checker
would refrain from turning red for any breaks that match what's in those
files. For instance I think in branch REL_18_STABLE we would add a
subdirectory like
/src/tools/abicheck-exclude/18.1
where we would store one exclusion file that suppresses reporting for
each ABI-breaking change between 18.0 and 18.1. (Or maybe name the
subdir REL_18_1).
So when we break ABI compatibility after having 18.0 out and before
releasing 18.1, the animal turns red and we'd either add a file there
or fix the ABI break -- both of which turn the animal back to green.
It's somewhat equivalent to valgrind.supp, except the files are
version-specific.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Once again, thank you and all of the developers for your hard work on
PostgreSQL. This is by far the most pleasant management experience of
any database I've worked on." (Dan Harris)
http://archives.postgresql.org/pgsql-performance/2006-04/msg00247.php
