Re: ABI Compliance Checker GSoC Project

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Mankirat Singh <mankiratsingh1315(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: ABI Compliance Checker GSoC Project
Date: 2026-01-29 09:37:20
Message-ID: CAEZATCUEKpdBq5WXk+ca=EpDTCjYL1ww=TifrfzwtLLRErEX+A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 25 Jan 2026 at 21:01, David E. Wheeler <david(at)justatheory(dot)com> wrote:
>
> On Jan 25, 2026, at 15:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Yeah, exactly. The point here is we want the complaint about
> > TransitionCaptureState but not the one about AfterTriggersTableData.
>
> Okay, great. Hopefully it’ll start passing again once Dean pushes the .abi-compliance-history patch.
>

OK, baza is now showing the 1 artifact change that I would expect
(TransitionCaptureState) [1-4]. That should go away after I push my
change to .abi-compliance-history.

However, crake is now showing between 4 and 17 artifacts changes
[5-8]. Apart from the 1 expected failure, the rest appear to have
nothing to do with any recent commits.

For example, this:

'enum manifest_option' changed:
type size hasn't changed
3 enumerator deletions:
'manifest_option::MANIFEST_OPTION_YES' value '0'
'manifest_option::MANIFEST_OPTION_NO' value '1'
'manifest_option::MANIFEST_OPTION_FORCE_ENCODE' value '2'

which doesn't make any sense. Those enum elements haven't been
deleted, and have been unchanged since they were added in commit
f88798c, which was before PG15 was released.

The other reports on crake don't make any sense to me either, so what
has changed on crake, and how is it different from baza?

Regards,
Dean

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=baza&dt=2026-01-26%2012%3A28%3A17
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=baza&dt=2026-01-26%2012%3A59%3A20
[3] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=baza&dt=2026-01-27%2012%3A00%3A04
[4] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=baza&dt=2026-01-28%2012%3A00%3A04

[5] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-01-26%2019%3A52%3A03
[6] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-01-26%2020%3A20%3A23
[7] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-01-29%2003%3A42%3A07
[8] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-01-29%2007%3A22%3A04

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-01-29 09:56:32 Improvements and refactoring in shmem.c
Previous Message Dilip Kumar 2026-01-29 09:24:58 Re: unnecessary executor overheads around seqscans