Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id 1733767.1760732382@sss.pgh.pa.us
Whole thread Raw
In response to Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
List pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Fri, Oct 17, 2025 at 03:52:18PM -0400, David E. Wheeler wrote:
>> If there is a tag _AFTER_ the listed SHA, should we prefer that tag as
>> the baseline?

> I don't see any need to consider tags at all.  We'd initialize this file
> when creating the new STABLE branch with a baseline commit near a release
> candidate or the .0, and then we'd just add future baselines as needed.
> The ABI checks would always use the latest baseline, even if it points to
> something before the latest release tag.  (At least, this is how I'm
> thinking about it.)

I agree.  I don't think the buildfarm should consider git tags at all
in this behavior.  One reason is that our release process dictates
applying tags at very specific times that aren't necessarily relevant
to deciding that an ABI break is or is not okay.  I think we want
moving the baseline to be a considered reaction to an observed ABI
report, and not an action that is automatic according to some other
process.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Next
From: Justin Pryzby
Date:
Subject: pg18: leaks io-uring FDs during restart_after_crash