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: Peter Geoghegan <pg@bowt.ie>, pgsql-hackers@postgresql.org, david@justatheory.com, Andrew Dunstan <andrew@dunslane.net>
Date: 2025-10-17T20:06:10Z
Lists: pgsql-hackers 
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Fri, Oct 17, 2025 at 03:53:09PM -0400, Tom Lane wrote:
>> I don't see a race condition here.  What would happen is we make
>> some commit, realizing either at the time or later that it involves
>> an ABI break.  We verify via some later buildfarm run that the
>> break is as-expected (ie the commit doesn't introduce any unwanted
>> changes, nor is there anything hanging around from some older commit).
>> Then we push an update to the .abi_reference file that points at
>> that commit,

> Ah, I was thinking of a more proactive approach (e.g., I commit something
> that I know introduces ABI breakage, and then I immediately update the ABI
> reference file in the next commit).  I like the idea of simply reacting to
> the reports and using that as an opportunity to verify it's what we expect.

Right.  This does mean that those BF members might stay red for a
little bit while we verify that we're seeing expected results, but
I think that's acceptable.  Trying to prevent the BF from ever
seeing a bad state seems to me to carry too much risk of masking
problems we didn't expect.

			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.