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 1vBIjt-00EmGf-2J for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Oct 2025 20:13:48 +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 1vBIjs-00BbYG-1t for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Oct 2025 20:13:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vBIjr-00BbY7-OK for pgsql-hackers@lists.postgresql.org; Tue, 21 Oct 2025 20:13:46 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vBIjo-003UHf-0b for pgsql-hackers@lists.postgresql.org; Tue, 21 Oct 2025 20:13:46 +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 59LKDbi9655241; Tue, 21 Oct 2025 16:13:37 -0400 From: Tom Lane To: Nathan Bossart cc: "David E. Wheeler" , Mankirat Singh , pg@bowt.ie, andrew@dunslane.net, pgsql-hackers@lists.postgresql.org Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() In-reply-to: References: <230647.1760971159@sss.pgh.pa.us> <334460.1760980024@sss.pgh.pa.us> <351026.1760988833@sss.pgh.pa.us> <1A5A7BE9-4A1B-4A1E-9182-02EBE9A54721@justatheory.com> Comments: In-reply-to Nathan Bossart message dated "Tue, 21 Oct 2025 12:30:32 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <655239.1761077617.1@sss.pgh.pa.us> Date: Tue, 21 Oct 2025 16:13:37 -0400 Message-ID: <655240.1761077617@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > For the rest of the back-branches, I'm considering starting with a baseline > of the latest minor version stamps. While it would be nice to have a > comprehensive history of the ABI compatibility for each major version, > we've lived this long without it, and I think it's unlikely that we'd act > on any breakages that predate the latest release set. Thoughts? Agreed that building a full list of ABI-changing commits in those branches is probably not worth the trouble at this point. (My OCD side kind of wants to do it anyway ... but it's hard to argue that we'd get real value out of it, or that we'd change anything now unless we get complaints.) I searched the commit log, and found that the most recent intentional, or at least documented-in-the-log, ABI break was here: Author: Masahiko Sawada Branch: master Release: REL_18_BR [d87d07b7a] 2025-06-16 17:36:01 -0700 Branch: REL_17_STABLE Release: REL_17_6 [45c357e0e] 2025-06-16 17:35:58 -0700 Branch: REL_16_STABLE Release: REL_16_10 [b2ae07720] 2025-06-16 17:35:55 -0700 Branch: REL_15_STABLE Release: REL_15_14 [fc0fb77c5] 2025-06-16 17:35:53 -0700 Branch: REL_14_STABLE Release: REL_14_19 [983b36362] 2025-06-16 17:35:50 -0700 Branch: REL_13_STABLE Release: REL_13_22 [1230be12f] 2025-06-16 17:35:48 -0700 ... Note that this commit adds two new fields to ReorderBufferTXN to store the distributed transactions. This change breaks ABI compatibility in back branches, affecting third-party extensions that depend on the size of the ReorderBufferTXN struct, though this scenario seems unlikely. ... I propose that we should make .abi-compliance-history point at these commits rather than REL_17_6 et al. If there is anything later than this that affected ABI, it'd be worth finding out I think, even though we might choose not to do anything about it. (In effect, we'd be starting the ABI compliance histories there rather than all the way back at the .0 releases.) regards, tom lane