file_extend_method is an escape hatch wearing the costume of a tuning knob. It exists for one purpose: to let you turn off a PostgreSQL 16 optimization on the filesystems where that optimization turned out to misbehave.
When a table grows, PostgreSQL has to extend its data file, and there are two ways to do that. posix_fallocate asks the operating system to reserve the disk space through the standard POSIX call, without writing anything into it; write_zeros extends the file the old-fashioned way, by physically writing out blocks of zeroes. The parameter is an enum choosing between them, it is sighup so it reloads without a restart, and its default is posix_fallocate on any system that has the function. On a system that does not, macOS being the obvious one, write_zeros is the only value on offer and the setting has nothing to switch.
The reason both exist is a piece of history. PostgreSQL 16 started using posix_fallocate for bulk relation extension, because reserving space up front is faster than writing zeroes and leaves the file less fragmented. That is the right call almost everywhere. But posix_fallocate has two filesystem-specific problems that people hit in the field: on Btrfs, preallocating with it disables compression on the file, so anyone relying on transparent compression silently loses it; and on XFS, some Linux kernel versions returned spurious “no space left on device” errors from the fallocate path, a bug since reported fixed. file_extend_method = write_zeros is the way out of both. It reverts to the pre-16 method and never calls posix_fallocate at all.
What makes this parameter unusual is how it arrived. New GUCs are a major-version affair; they land in the next annual release and nowhere else. This one did not. It was committed in early 2026 and backpatched all the way through PostgreSQL 16, precisely because it is a workaround for damage users were taking in production rather than a feature anyone was waiting for. So it is not a “new in 18” setting despite showing up in the version 18 documentation; it is in current 16, 17, and 18 alike.
Two details in the small print. First, the switch only governs bulk extension: any operation that grows a file by eight blocks (64 kB) or fewer always uses write_zeros regardless of the setting, so what you are really choosing is how the server extends files during heavier work like a large COPY. Second, even when you ask for posix_fallocate, a filesystem that does not support fallocate makes the server fall back to write_zeros on its own.
So leave it at the default. posix_fallocate is the faster path and it is fine on ext4 and on XFS with a current kernel. Switch to write_zeros only for a specific reason: you are on Btrfs and want your compression back, or you are pinned to a kernel with the XFS bug. This is a remedy for a named ailment, not a dial you turn for more speed.