| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, david(at)justatheory(dot)com, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |
| Date: | 2025-10-17 19:20:55 |
| Message-ID: | CAH2-WznQY7UaGGdAgg0crnJ8j1R3MW8rMqEynDBMTio+7WAYXA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 17, 2025 at 3:11 PM Nathan Bossart <nathandbossart(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-10-17 19:27:10 | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |
| Previous Message | Nathan Bossart | 2025-10-17 19:11:10 | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |