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.96) (envelope-from ) id 1vqbzh-00ELbe-05 for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Feb 2026 19:04:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vqbzg-00AdLl-0H for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Feb 2026 19:04:52 +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.96) (envelope-from ) id 1vqbzf-00AdLa-2Y for pgsql-hackers@lists.postgresql.org; Thu, 12 Feb 2026 19:04:52 +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.98.2) (envelope-from ) id 1vqbzb-00000000Meu-1Px8; Thu, 12 Feb 2026 19:04:52 +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 61CJ4dF8351363; Thu, 12 Feb 2026 14:04:39 -0500 From: Tom Lane To: Peter Eisentraut cc: Andrew Dunstan , "David E. Wheeler" , Michael Paquier , Thomas Munro , pgsql-hackers Subject: Re: pgsql: Add file_extend_method=posix_fallocate,write_zeros. In-reply-to: <286104.1770911626@sss.pgh.pa.us> References: <10e5526f-364c-4867-b6f7-91f13a9494e4@eisentraut.org> <286104.1770911626@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 12 Feb 2026 10:53:46 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <351361.1770923079.1@sss.pgh.pa.us> Date: Thu, 12 Feb 2026 14:04:39 -0500 Message-ID: <351362.1770923079@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Peter Eisentraut writes: >> I suppose technically this is an ABI change since the size of >> ConfigureNamesEnum is changed, but it seems this is irrelevant in >> practice. Could it be possible to ignore stuff like this without manual >> intervention? > I am working on a bug report to libabigail, arguing that this should > not be reported as an ABI diff (at least not in --headersdir mode). So I tried to make a small reproducer, and failed. Then I ran the buildfarm script (with abidiff enabled) against c6881f79228, right before the last .abi-compliance-history update, and it passed. IOW, the version of abidiff I have here does not seem to have this bug. It's 2.8.0 from last July or so. Now I'm wondering exactly what libabigail releases crake and baza are using. regards, tom lane