Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: "David E. Wheeler" <david@justatheory.com>, pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>, Mankirat Singh <mankiratsingh1315@gmail.com>
Date: 2025-10-17T20:19:42Z
Lists: 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

Commits

  1. Add commit 24f6c1bd4 to v17 .abi-compliance-history.

  2. Add .abi-compliance-history to back-branches.

  3. Add reminder to create .abi-compliance-history.

  4. Update .abi-compliance-history file.

  5. Add .abi-compliance-history to v18 branch.

  6. Fix thinko in commit 7d129ba54.

  7. Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().

  8. Add defenses against unexpected changes in the NodeTag enum list.