Re: ABI Compliance Checker GSoC Project - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: ABI Compliance Checker GSoC Project
Date
Msg-id DC3F6A36-1512-494C-85F5-56BC4B9756D1@justatheory.com
Whole thread Raw
In response to Re: ABI Compliance Checker GSoC Project  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
On Sep 1, 2025, at 09:12, David E. Wheeler <david@justatheory.com> wrote:

>> Also, I think we can also have a configuration option for animal owners to toggle ABI change status on or off,
thoughts?
>
> Mabye? Might be worth waiting to see how much of an issue it is. If there is a failure a then a fix, it should turn
greenagain. It might not be necessary. 
>
> What do you think, Hackers?

I had baza configured to test ABI changes since the .1 tags for each of the maintenance branches for the past few days
togive a feel for what those failures look like. It was easy to configure: 

    tag_for_branch => {
        REL_17_STABLE => 'REL_17_1',
        REL_16_STABLE => 'REL_16_1',
        REL_15_STABLE => 'REL_15_1',
        REL_14_STABLE => 'REL_14_1',
        REL_13_STABLE => 'REL_13_1',
    }

You can see the results from today here:

REL_18_RC1 -> f256a7b

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=baza&dt=2025-09-08%2012%3A42%3A42&stg=abi-compliance-check

REL_17_1 -> 3e6dfcf

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=baza&dt=2025-09-08%2012%3A28%3A55&stg=abi-compliance-check

REL_16_1 -> 12f5768

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=baza&dt=2025-09-08%2012%3A14%3A10&stg=abi-compliance-check

REL_15_1 -> 1852ec5

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=baza&dt=2025-09-08%2012%3A00%3A02&stg=abi-compliance-check

REL_14_1 -> ea65c88

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=baza&dt=2025-09-05%2012%3A10%3A11&stg=abi-compliance-check

REL_13_1 -> dbef9cb

https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=baza&dt=2025-09-05%2012%3A00%3A02&stg=abi-compliance-check

The RC1 change surprised me a little; here’s the log:

> Leaf changes summary: 1 artifact changed
> Changed leaf types summary: 0 leaf type changed
> Removed/Changed/Added functions summary: 0 Removed, 1 Changed, 0 Added function
> Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
>
> 1 function with some sub-type change:
>
> [C] 'function void CheckValidResultRel(ResultRelInfo*, CmdType, List*)' has some sub-type changes:
> parameter 4 of type 'List*' was added
> parameter 3 of type 'List*' changed:
> entity changed from 'List*' to 'typedef OnConflictAction'
> type size changed from 8 to 4 (in bytes)
> type alignment changed from 0 to 4

Presumably this is expected, but it looks like it might be an issue if it weren’t a pre-release change, yes?

In any event, I’ve restored the default configuration so that tomorrow’s builds will start comparing from the latest
tagin each branch, which should return all but REL_18_STABLE to passing again. 

Anyone else interested in trying out the compliance checker on their build farm animals? It works only on Linux for
now,I believe. 

Best,

David




Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: A performance regression issue with Memoize
Next
From: Paul Ohlhauser
Date:
Subject: Re: [PG19-3 PATCH] Don't ignore passfile