Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
| От | Peter Geoghegan |
|---|---|
| Тема | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |
| Дата | |
| Msg-id | CAH2-Wzne4pkk+jEg0vQC8qSdqHHqt64HHRgkzud3hvkGWKNnjA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
|
| Список | pgsql-hackers |
On Fri, Oct 17, 2025 at 3:28 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > 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. You said "I suppose this idea is entirely dependent on the maintainers of the abi-compliance-check code to adapt to it", which I understood to mean that you thought that the upstream tool would somehow be made to accept these kinds of ignore files. Obviously I misunderstood. > 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). In practice I think that it would be up to the person writing the next suppression to verify that there were no unrelated changes in the interim between their new blessed/suppression commit and the prior one. That doesn't seem super onerous to me, given that even false positives don't seem to be all that common with abi-compliance-checker. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: