Horton

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

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: "David E. Wheeler" <david@justatheory.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>, Mankirat Singh <mankiratsingh1315@gmail.com>
Date: 2025-10-17T20:11:35Z
Lists: pgsql-hackers 
On Fri, Oct 17, 2025 at 03:52:18PM -0400, David E. Wheeler wrote:
> Adding Mankirat, who developed the ABI checker for his GSoC project.

Thanks for chiming in.

> Is the idea that the ABI checker just has to scan the first non-comment
> line that starts with a commit identifier (SHA or tag)?

Yes.

> Seems totally do-able, though I don’t know what that `(Apple Git-154)`
> bit is doing at the end.

I think that's just telling you what version of git I used to create the
patch file.

> I presume it would list the history of changes in reverse chronological
> order, yes?

Yes, although we could change it to whatever we want.

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

-- 
nathan

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.