On Fri, Oct 17, 2025 at 03:53:09PM -0400, Tom Lane wrote: > 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.
Ah, I was thinking of a more proactive approach (e.g., I commit something that I know introduces ABI breakage, and then I immediately update the ABI reference file in the next commit). I like the idea of simply reacting to the reports and using that as an opportunity to verify it's what we expect. -- nathan
