Обсуждение: Development of ABI Compliance Checker for official PostgreSQL Repo

> On 16 May 2025, at 02:42, Mankirat Singh <mankiratsingh1315@gmail.com> wrote:
>
> Hello Postgres Community,
>
> I am Mankirat - 3rd year Computer Engineering undergrad. I am excited to share that I will be developing an ABI
compliancechecker and reporting system this summers as my GSoC 2025 project under the mentorship of David Wheeler and
PavloGolub. 

Welcome to the community, we look forward to seeing your work!

--
Daniel Gustafsson

On 18.05.25 20:29, David E. Wheeler wrote:
> On May 16, 2025, at 02:42, Mankirat Singh <mankiratsingh1315@gmail.com> wrote:
> 
>> I had wrote two blogs for the same discussing about importance of this project and how I plan to work on this at
blog.mankiratsingh.comI’d greatly appreciate any feedback or suggestions.
 
> 
> Anyone have thoughts on Mankirat’s proposal[1] to start with libabigail’s abidiff utility to produce the the raw data
foreach report, and then write Perl code to transform it to a publishable report?
 

Well, normally (if there are no problematic ABI changes) the report will 
be empty.  So I wouldn't spend too much time on the formatting.  If 
there is a violation, you can just show the raw abidiff output inside 
<pre> or whatever.

Generally, this looks like the right direction.

As an additional tip, check the Python source code, they are doing 
something like that with libabigail as well.

> 
> Best,
> 
> David
> 
> [1]: https://blog.mankiratsingh.com/posts/abi-compliance-reporting-part-2/
> 

On May 19, 2025, at 10:17, Peter Eisentraut <peter@eisentraut.org> wrote:

> Well, normally (if there are no problematic ABI changes) the report will be empty.  So I wouldn't spend too much time
onthe formatting.  If there is a violation, you can just show the raw abidiff output inside <pre> or whatever. 

Interesting point, though it looks like maybe the output doesn’t work that way? In his second post, Mankirat linked to
theoutput from abidiff[1] and abicc[2] comparing 17.2 to 17.3. The latter is HTML, but abidiff’s plan is pretty
straightforwardtext that reports a bunch of changes. I imagine it’ll need some massaging to determine which are proper
ABIbreaks. 

Mankirat, did you try it with 17.0 to 17.1? That would be interesting, as there was an ABI break in 17.1[3].

> Generally, this looks like the right direction.
>
> As an additional tip, check the Python source code, they are doing something like that with libabigail as well.

Ooh, good to know, thanks!

D

[1]: https://drive.google.com/file/d/1EFW2BHsRglAuNTjF6DpizRiX8iSNBsaN/view
[2]: https://abicc-17-2-17-3-postgres.mankiratsingh.com/
[3]: https://www.enterprisedb.com/blog/explaining-abi-breakage-postgresql-171

On May 21, 2025, at 09:53, Mankirat Singh <mankiratsingh1315@gmail.com> wrote:

> Would it be good idea if I write an in general tool for this purpose and then use it for build farm extension as
othertools in the open source community might also need the same? 

I certainly always appreciate that approach, yes.

Best,

David

On 21.05.25 14:52, Mankirat Singh wrote:
> On Wed, 21 May 2025 at 00:27, David E. Wheeler <david@justatheory.com 
> <mailto:david@justatheory.com>> wrote:
> 
>     Interesting point, though it looks like maybe the output doesn’t
>     work that way? In his second post, Mankirat linked to the output
>     from abidiff[1] and abicc[2] comparing 17.2 to 17.3. The latter is
>     HTML, but abidiff’s plan is pretty straightforward text that reports
>     a bunch of changes. I imagine it’ll need some massaging to determine
>     which are proper ABI breaks.
> 
>     Mankirat, did you try it with 17.0 to 17.1? That would be
>     interesting, as there was an ABI break in 17.1[3].
> 
> I have attached below the compliance reports for that version. I had not 
> included it in the blog earlier, as it was complicated and some readers 
> might not understand.
> 
> But as per my understanding, the outputs given by abidiff are way too 
> detailed as compared to html report output by abi-compliance-checker for 
> the same PostgreSQL version, though it backfires abidiff's usefulness 
> since it lists all the symbols which got affected due to a change 
> instead of directly mentioning the root cause.
> For example, in version 17.1 instability struct ResultRelInfo got 
> changed with a new data member, in execnodes.h file as per this blog[1], 
> but the abidiff report gives "14 functions with some indirect sub-type 
> change" and all those 14 were affected due to the same cause, i.e. 
> ResultRelInfo struct - thus making a need to parse the output in a 
> better format, I believe.

First, you should use abidiff --no-added-syms, to remove all the output 
about added symbols.

And then you should create a suppression file so that situations like 
the above can be checked and added to an approved list.

I think it is essential for this project that the output is empty if 
there are no problems ("no news is good news").  No one will want to dig 
through the output if it produces warnings about harmless things.