Subject: pgsql: Add file_extend_method=posix_fallocate,write_zeros.

From: Thomas Munro <[email-masked]>
Date: Fri, 06 Feb 2026 05:09:54 +0000

Add file_extend_method=posix_fallocate,write_zeros.

Provide a way to disable the use of posix_fallocate() for relation
files.  It was introduced by commit 4d330a61bb1.  The new setting
file_extend_method=write_zeros can be used as a workaround for problems
reported from the field:

 * BTRFS compression is disabled by the use of posix_fallocate()
 * XFS could produce spurious ENOSPC errors in some Linux kernel
   versions, though that problem is reported to have been fixed

The default is file_extend_method=posix_fallocate if available, as
before.  The write_zeros option is similar to PostgreSQL < 16, except
that now it's multi-block.

Backpatch-through: 16
Reviewed-by: Jakub Wartak <[email-masked]>
Reported-by: Dimitrios Apostolou <[email-masked]>
Discussion: https://postgr.es/m/b1843124-fd22-e279-a31f-252dffb6fbf2%40gmx.net

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/33e3de6d77e87d6c3c6f8f878dd8de42d37c3b8f

Modified Files
--------------
doc/src/sgml/config.sgml                      | 37 +++++++++++++++++++++++++++
src/backend/storage/file/fd.c                 |  3 +++
src/backend/storage/smgr/md.c                 | 21 +++++++++++----
src/backend/utils/misc/guc_tables.c           | 19 ++++++++++++++
src/backend/utils/misc/postgresql.conf.sample |  4 +++
src/include/storage/fd.h                      | 11 ++++++++
6 files changed, 90 insertions(+), 5 deletions(-)

---

From: Michael Paquier <[email-masked]>
Date: Fri, 6 Feb 2026 20:30:37 +0900

Hi Thomas,

> Add file_extend_method=posix_fallocate,write_zeros.

It looks like you need to update .abi-compliance-check for stable
branches down to v16, due to the new entry added to
ConfigureNamesEnum.  See:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-02-06%2009%3A27%3A27
--
Michael

---

From: Thomas Munro <[email-masked]>
Date: Sat, 7 Feb 2026 01:57:27 +1300

> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-02-06%2009%3A27%3A27

Ahh, right, I see (I was asking about this on the patch thread, as I
hadn't had to do that before).  Will do in a few hours, sorry for the
build farm noise.  Thanks!

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 12 Feb 2026 13:02:12 +0100

> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-02-06%2009%3A27%3A27

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?

The concern is that say authors or packagers of extensions will observe 
that there was an ABI change and will think they have to do some extra 
work, but in practice probably not.

The goal should be to not have ABI changes in stable branches.  If we 
just keep marking ABI changes without distinction, then this could lead 
to fatigue.

---

From: Tom Lane <[email-masked]>
Date: Thu, 12 Feb 2026 10:53:46 -0500

> practice.  Could it be possible to ignore stuff like this without manual 

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).
That's at best a long-term solution, but on the other hand it's
not every day that we add a new GUC to back branches.

There was upthread discussion about using a suppression file, but
that'd require some testing to ensure that it does what we want
and nothing more nor less.  (For instance, if suppressing
ConfigureNamesEnum resulted in no complaints about changes in
struct config_enum, that'd be very bad.)

Keep in mind also that libabigail seems to have some nasty blind
spots.  (I'm about to post something to pgsql-hackers about one that
I found last week.)

For the time being, I think we'd be well advised to treat the abidiff
reports as an experimental work-in-progress.  They might eventually
get to the level of trustworthiness that you seem to be envisioning,
but we're not there yet.

			regards, tom lane

---

From: Tom Lane <[email-masked]>
Date: Thu, 12 Feb 2026 14:04:39 -0500

> 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

---

From: "David E. Wheeler" <[email-masked]>
Date: Fri, 13 Feb 2026 09:23:14 -0500

> Now I'm wondering exactly what libabigail releases crake and baza

Baza has 2.2.0, installed from Bookworm packaging. I can see about upgrading it this weekend, either building from source or making a new VM with Trixie.

D