Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id aPKY4fJVgKrX76p-@nathan
Whole thread Raw
In response to Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
List pgsql-hackers
On Fri, Oct 17, 2025 at 03:20:55PM -0400, Peter Geoghegan wrote:
> On Fri, Oct 17, 2025 at 3:11 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> Anything else?  I suppose this idea is entirely dependent on the
>> maintainers of the abi-compliance-check code to adapt to it, so we'll need
>> buy-in from them, too.
> 
> That would require parsing the file and understanding that any
> compliance failures associated with a given commit should be
> suppressed. But that seems decidedly nontrivial to me. I can easily
> think of (admittedly somewhat contrived) scenarios where it's
> basically impossible to make this work due to transitive dependencies
> across commits.

I was imagining this working more like what Tom suggested.  IOW we'd use
the latest commit listed in the file (perhaps always the first one) as the
baseline.  Of course, this doesn't work too well if we have a bunch of ABI
breaks between buildfarm checks.  But my guess is that we could deal with
that pretty easily (e.g., make sure the buildfarm member in question runs
for every commit on the stable branch).

-- 
nathan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Next
From: Tom Lane
Date:
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()