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>
Subject: Re: abi-compliance-check failure due to recent changes to
 pg_{clear,restore}_{attribute,relation}_stats()
In-reply-to: <aPKbY4vzdNWoKloK@nathan>
References: <aPJ03E2itovDBcKX@nathan> <1713509.1760721320@sss.pgh.pa.us>
 <aPKFmL8VjOKNVLcw@nathan> <1723302.1760726712@sss.pgh.pa.us>
 <aPKUzk2xFhZBbWmz@nathan>
 <CAH2-WznQY7UaGGdAgg0crnJ8j1R3MW8rMqEynDBMTio+7WAYXA@mail.gmail.com>
 <aPKY4fJVgKrX76p-@nathan>
 <CAH2-Wzne4pkk+jEg0vQC8qSdqHHqt64HHRgkzud3hvkGWKNnjA@mail.gmail.com>
 <aPKbY4vzdNWoKloK@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Fri, 17 Oct 2025 14:39:15 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1730701.1760730789.1@sss.pgh.pa.us>
Date: Fri, 17 Oct 2025 15:53:09 -0400
Message-ID: <1730702.1760730789@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1730702.1760730789%40sss.pgh.pa.us>
Precedence: bulk

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