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

From Robert Haas
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id CA+Tgmob2gLaDeeJDjCtWe_xuac1XkTmip4raR_4isYMvkO0yBw@mail.gmail.com
Whole thread Raw
In response to Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
On Thu, Oct 30, 2025 at 8:42 AM David E. Wheeler <david@justatheory.com> wrote:
> Might I suggest, however, that it also run for branches matching /_STABLE$/ even if there is no .abi-hstory-file? The
wholepoint of this exercise was to increase the confidence in ABI stability in stable branches. Running it in such
brancheswould help remind maintainers to add the file. 

I think it is better to do as Tom suggests -- i.e. have a buildfarm
client that only cares about the presence of the file, and not at all
about the name of the branch. That gives us the maximum amount of
future flexibility for no real cost. Said differently, if somebody
nukes the ABI history file from a back-branch, I think we should
assume that represents a deliberate decision on the part of the
project to stop caring about ABI compatibility in that particular
back-branch, not an error that the build-farm needs to flag. Of
course, if somebody wants to argue that such a decision was wrongly
made, they're free to do so on pgsql-hackers, but we'd like the
buildfarm to be green rather than red while that's being litigated.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: another autovacuum scheduling thread
Next
From: Andres Freund
Date:
Subject: Re: Upgrade macOS CI image from Sonoma to Sequoia