Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, pgsql-hackers@postgresql.org,
david@justatheory.com, Andrew Dunstan <andrew@dunslane.net>
Date: 2025-10-17T19:53:09Z
Lists: pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes: > On Fri, Oct 17, 2025 at 03:33:28PM -0400, Peter Geoghegan wrote: >> 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. I don't see a race condition here. What would happen is we make some commit, realizing either at the time or later that it involves an ABI break. We verify via some later buildfarm run that the break is as-expected (ie the commit doesn't introduce any unwanted changes, nor is there anything hanging around from some older commit). Then we push an update to the .abi_reference file that points at that commit, and the buildfarm starts comparing ABI of branch tip to that commit instead of whatever was the reference commit before. No later activity breaks the conclusion that we were okay with the ABI that that commit creates, nor can any earlier commit cause problems so long as we did our due diligence in checking the ABI-break reports. In theory, if two ABI-breaking commits go in so close together that there was no ABI-checking buildfarm run in between, we might have difficulty untangling their effects. That doesn't seem very likely in practice, and even if it happens, so what? Either we're good with the ABI-break report when we see it, or we're not. regards, tom lane
Commits
-
Add commit 24f6c1bd4 to v17 .abi-compliance-history.
- 5c659da980e1 17.7 landed
-
Add .abi-compliance-history to back-branches.
- eaf73340cd46 16.11 landed
- d9c5e7129d2b 15.15 landed
- a91f2d822522 17.7 landed
- 7d47278933f4 13.23 landed
- 58ba7e5ebfdf 14.20 landed
-
Add reminder to create .abi-compliance-history.
- b97d8d843a2d 19 (unreleased) landed
-
Update .abi-compliance-history file.
- 93fb76ca4e69 18.1 landed
-
Add .abi-compliance-history to v18 branch.
- a72f7d97bea9 18.1 landed
-
Fix thinko in commit 7d129ba54.
- 399a9e04e549 18.1 cited
-
Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().
- c8af5019bee5 18.1 cited
- 688dc6299a5b 19 (unreleased) cited
-
Add defenses against unexpected changes in the NodeTag enum list.
- eea9fa9b250f 16.0 cited