Date: Fri, 17 Oct 2025 14:28:33 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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()
Message-ID: <aPKY4fJVgKrX76p-@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAH2-WznQY7UaGGdAgg0crnJ8j1R3MW8rMqEynDBMTio+7WAYXA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aPKY4fJVgKrX76p-%40nathan>
Precedence: bulk

On Fri, Oct 17, 2025 at 03:20:55PM -0400, Peter Geoghegan wrote:
> On Fri, Oct 17, 2025 at 3:11 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> Anything else?  I suppose this idea is entirely dependent on the
>> maintainers of the abi-compliance-check code to adapt to it, so we'll need
>> buy-in from them, too.
> 
> That would require parsing the file and understanding that any
> compliance failures associated with a given commit should be
> suppressed. But that seems decidedly nontrivial to me. I can easily
> think of (admittedly somewhat contrived) scenarios where it's
> basically impossible to make this work due to transitive dependencies
> across commits.

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.  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).

-- 
nathan