Subject: Re: [PING] fallocate() causes btrfs to never compress postgresql files

From: Andrew Dunstan <[email-masked]>
Date: Fri, 6 Feb 2026 10:33:55 -0500

On 2026-02-06 Fr 10:11 AM, Tom Lane wrote:
> Thomas Munro <[email-masked]> writes:
>> BTW the rest of the patches will reemerge for master, but for the
>> minimal one back-patched: crake complains about an ABI break due to
>> GUC table changes.  Of course adding a GUC to the stable branches is
>> unusual and we discussed the need for it in this case.  Is that
>> expected?  In what way is it part of the ABI?  How would one determine
>> in advance that the ABI checker will complain?
> We have very little experience so far with libabigail, so there's
> not any store of knowledge hereabouts on what it'll complain about.
>
> The message is complaining that sizeof(ConfigureNamesEnum) changed,
> which it did, but I don't see how that value would be visible to
> external modules.  So maybe a bug in libabigail?
>
> 			

I guess because of this in guc_tables.h:

extern PGDLLIMPORT struct config_generic ConfigureNames[];

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

---

From: Tom Lane <[email-masked]>
Date: Fri, 06 Feb 2026 13:31:02 -0500

> extern PGDLLIMPORT struct config_generic ConfigureNames[];

Evidently, but I don't see how that provides a sizeof() value to
onlookers.  Just to be sure, I tried to compile a use of that,
and got

test.c:43:53: error: invalid application of ‘sizeof’ to incomplete type ‘struct config_generic[]’
  elog(NOTICE, "sizeof(ConfigureNames) = %zu", sizeof(ConfigureNames));
                                                     ^

So if this isn't an outright bug, it's at least unhelpful behavior.

			regards, tom lane

---

From: Andrew Dunstan <[email-masked]>
Date: Fri, 6 Feb 2026 15:16:25 -0500

> So if this isn't an outright bug, it's at least unhelpful behavior.

Fair enough. I agree it's not terribly helpful. In any case, maybe we 
need to look at my earlier suggestion of adding a suppression file.

cheers

andrew

---

From: Tom Lane <[email-masked]>
Date: Fri, 06 Feb 2026 15:31:03 -0500

> need to look at my earlier suggestion of adding a suppression file.

Perhaps, but since we're getting pretty hard up against the release
freeze deadline, I think the thing to do for today is just to update
.abi-compliance-history.  We know that way works.

			regards, tom lane

---

From: Thomas Munro <[email-masked]>
Date: Sat, 7 Feb 2026 11:07:00 +1300

> .abi-compliance-history.  We know that way works.

So it seems I need to do the attached for 18, and the same again for
17 and 16.  Look about right?

I peeked at the libabigail man page, and I don't see any discussion of
incomplete types, but it looks like OPAQUE_TYPE_LABEL might be a way
to tell it about this.  If that works, wouldn't it be better than
doing this forever?  Where would that be configured?
From a209e9c5cfeef91aa597d83854b1d448cf2c7617 Mon Sep 17 00:00:00 2001
From: Thomas Munro <[email-masked]>
Date: Sat, 7 Feb 2026 10:56:04 +1300
Subject: [PATCH] Tell ABI checker that 33e3de6d is OK.

It's not really an ABI break if you change the layout/size of an object
with incomplete type.

Discussion: https://www.postgresql.org/message-id/1871492.1770409863%40sss.pgh.pa.us
---
 .abi-compliance-history | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/.abi-compliance-history b/.abi-compliance-history
index f4e27cfb160..420ad2c3aa1 100644
--- a/.abi-compliance-history
+++ b/.abi-compliance-history
@@ -18,6 +18,16 @@
 # Be sure to replace "<ADD JUSTIFICATION HERE>" with details of your change and
 # why it is deemed acceptable.
 
+33e3de6d77e87d6c3c6f8f878dd8de42d37c3b8f
+#
+# Add file_extend_method=posix_fallocate,write_zeros.
+# 2026-02-06 17:38:39 +1300
+#
+# Modifying GUC tables isn't really an ABI break: the relevant object has
+# incomplete type so its layout is inaccessible from C.
+#
+# Discussion: https://www.postgresql.org/message-id/flat/e1f0cd3b-0164-45f5-9705-e922e59df90f%40dunslane.net#8a350b54012c0042f9869d288e978cfe
+
 492a69e1407029f8c673484f44aa719a63323d77
 #
 # Reject ADD CONSTRAINT NOT NULL if name mismatches existing constraint
-- 
2.52.0