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

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