From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: 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()
Date: Fri, 17 Oct 2025 15:53:09 -0400
Message-ID: <1730702.1760730789@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, nathandbossart@gmail.com, pg@bowt.ie, andrew@dunslane.net
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
In-Reply-To: <1730702.1760730789@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox