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 | aPKbY4vzdNWoKloK@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:33:28PM -0400, Peter Geoghegan wrote: > 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. Sorry, I wasn't clear there. >> 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. Agreed. Even if someone forgets to do that validation, the chances of missing something seem low. -- nathan
В списке pgsql-hackers по дате отправления: