From: Tom Lane <tgl@sss.pgh.pa.us>
To: David E. Wheeler <david@justatheory.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>
Cc: Mankirat Singh <mankiratsingh1315@gmail.com>
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date: Wed, 29 Oct 2025 22:49:24 -0400
Message-ID: <2944096.1761792564@sss.pgh.pa.us> (raw)
In-Reply-To: <A067B3A3-1CB8-44CC-A695-C5D4EDDE847A@justatheory.com>
References: <2923669.1761781931@sss.pgh.pa.us>
<A067B3A3-1CB8-44CC-A695-C5D4EDDE847A@justatheory.com>
"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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, david@justatheory.com, bruce@momjian.us, nathandbossart@gmail.com, andrew@dunslane.net, mankiratsingh1315@gmail.com
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
In-Reply-To: <2944096.1761792564@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox