Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
| От | Nathan Bossart |
|---|---|
| Тема | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |
| Дата | |
| Msg-id | aPKY4fJVgKrX76p-@nathan обсуждение исходный текст |
| Ответ на | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() (Peter Geoghegan <pg@bowt.ie>) |
| Ответы |
Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
|
| Список | 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 по дате отправления: