Attached is a html report that was generated by a tool called
abi-compliance-checker/abi-dumper [1][2] (by using
"abi-compliance-checker -l libTest ... ") . I deliberately introduced
2 ABI compatibility issues affecting postgres, just to see what the
tool had to say about it.
The first ABI issue I mocked up involved a breaking change to the
signature of a function with external linkage. Sure enough, this issue
(in CheckForSerializableConflictIn(), as it happens) appears in the
report as a medium severity item.
The second ABI issue I mocked up involved "filling-in" a hole in a
struct (a struct that appears in a header that could be included by an
extension) with a new field. In other words, the "put new field in
existing alignment padding" trick. This kind of difference is
generally believed to be non-breaking, and so is acceptable in point
releases. But the issue still appears as a low severity item in the
report. The report points out (quite reasonably) that my newly added
field won't be initialized by old code. In most cases this will be
fine, of course. It's just not something that should be taken for
granted.
Overall, I like the report format -- especially its severity scale. So
it seems like abi-compliance-checker has the potential to become a
standard release management tool for Postgres point releases. I can
imagine a community resource along the lines of
https://coverage.postgresql.org; an automatically generated archive of
theoretical/actual x86_64 ABI breaks in each point release. I'd
appreciate having greater visibility into these issues.
[1] https://github.com/lvc/abi-dumper
[2] https://manpages.debian.org/unstable/abi-dumper/abi-dumper.1.en.html
--
Peter Geoghegan