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: "David E. Wheeler" <david@justatheory.com>
Cc: Bruce Momjian <bruce@momjian.us>, Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>, Mankirat Singh <mankiratsingh1315@gmail.com>
Date: 2025-10-30T13:55:42Z
Lists: pgsql-hackers 
"David E. Wheeler" <david@justatheory.com> writes:
> Might I suggest, however, that it also run for branches matching /_STABLE$/ even if there is no .abi-hstory-file? The whole point of this exercise was to increase the confidence in ABI stability in stable branches. Running it in such branches would help remind maintainers to add the file.

Trouble is, you then need an arbitrary client-made choice about which
commit to run the ABI check against.  If that code does something we
realize we don't want, we're back up against the problem of moving the
buildfarm configuration to fix it.  I'd rather the decision be opt-in.

(Also, the only rules I heard proposed for such client-driven choices
involved git tags.  I already explained why I don't want that: git
tags are hard to modify and subject to too many other constraints.)

			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.