Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vEIjG-009VvB-2w for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Oct 2025 02:49:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vEIjE-005KOi-MG for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Oct 2025 02:49:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vEIjE-005KOa-CU for pgsql-hackers@lists.postgresql.org; Thu, 30 Oct 2025 02:49:31 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vEIjB-004UOb-0B for pgsql-hackers@postgresql.org; Thu, 30 Oct 2025 02:49:30 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 59U2nO1p2944097; Wed, 29 Oct 2025 22:49:24 -0400 From: Tom Lane To: "David E. Wheeler" cc: Bruce Momjian , Nathan Bossart , pgsql-hackers@postgresql.org, Andrew Dunstan , Mankirat Singh Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() In-reply-to: References: <2923669.1761781931@sss.pgh.pa.us> Comments: In-reply-to "David E. Wheeler" message dated "Wed, 29 Oct 2025 20:49:35 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2944095.1761792564.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Oct 2025 22:49:24 -0400 Message-ID: <2944096.1761792564@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David E. Wheeler" writes: > On Oct 29, 2025, at 19:52, Tom Lane 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 ma= intain .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