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

From David E. Wheeler
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id 45D16ED3-8561-4287-8D39-E0345D4B46F6@justatheory.com
Whole thread Raw
In response to Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
List pgsql-hackers
On Oct 17, 2025, at 16:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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

Okay, so the rule is:

* If there is no .abi-compliance-history file, baseline from the latest tag
* Otherwise, baseline from the first SHA to appear in the file

Easy peasy.

D


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master
Next
From: Tom Lane
Date:
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()