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

From Peter Geoghegan
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id CAH2-WznQY7UaGGdAgg0crnJ8j1R3MW8rMqEynDBMTio+7WAYXA@mail.gmail.com
Whole thread Raw
In response to Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
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 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 suspect that any practical approach to solving this problem will
have to involve ignore files that look somewhat like a Valgrind
suppression file. It'll have to be based on symbol names, plus
possibly a specific ABI breakage  type.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Nathan Bossart
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()