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

From Tom Lane
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id 2944096.1761792564@sss.pgh.pa.us
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>)
Responses Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
List pgsql-hackers
"David E. Wheeler" <david@justatheory.com> writes:
> On Oct 29, 2025, at 19:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm asking to remove complexity, not add more.  The buildfarm client
>> should not be checking either branch names or git tags to control
>> this, when we have a perfectly good convention about the existence
>> of .abi-compliance-history to control it.

> We can remove the branch check, of course, but then you would have to maintain .abi-compliance-history in master, no?

No; my proposal was "don't run the ABI check unless the branch has
a .abi-compliance-history file".  master would normally not contain
such a file, thus no check.  As I was just discussing with Bruce,
we could put one there for awhile if we wanted to run ABI checks in
advance of forking a stable branch.

The reason I'm so allergic to having any of these decisions made on
the buildfarm-client side is years of herding cats^W^W trying to get
buildfarm owners to update their script versions and/or config files.
It's close to hopeless.  Thus, your proposal a message or three back
to add another BF client config setting to control this sounds like
the worst of all possible worlds.  If we needed a change in the
setting, getting the farm to converge to that would take months if not
years.  The idea that we could transiently enable checks between beta1
and branch fork on the basis of that approach is downright risible.
On the other hand, if the decisions are driven purely by what is in
our git tree, a change is the work of moments.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Logical Replication of sequences
Next
From: wenhui qiu
Date:
Subject: Re: another autovacuum scheduling thread