file_extend_method

file_extend_method — Selects the method used for extending data files. Observed in PG16–19 Beta 3; its last measured boot default is posix_fallocate in PG19 Beta 3, with sighup context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Selects the method used for extending data files.”

Identity

Type , Valueenum: Upstream pg_settings type
Context , Valuesighup: Takes effect after configuration reload
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Valueposix_fallocate, write_zeros: — for non-enum types
Category , ValueResource Usage / Disk: Upstream classification
Latest boot value , Valueposix_fallocate: posix_fallocate

Lifecycle

Fact	Value
First observed	PG16
Present in	PG16–19 Beta 3
Removed in	No
Introduction commit	`e37b59802846` — Add file_extend_method=posix_fallocate,write_zeros.
Commit date	2025-05-31
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG16–19 Beta 3	`posix_fallocate`	—	posix_fallocate

How it works

file_extend_method chooses how PostgreSQL grows relation files during bulk extension: posix_fallocate when available or explicit zero writes. Extensions of eight blocks or fewer still use zero writes.

The first supported method is platform dependent. posix_fallocate reserves space without writing every block, but unsupported file systems silently fall back; on current BTRFS it can disable compression for the file.

This affects allocation behavior and bulk-write latency, not WAL durability. Storage reservations, sparse-file behavior, compression, and copy-on-write semantics vary by file system. Its SIGHUP context allows configuration reload without a server restart.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Keep file_extend_method at the detected/default value unless operating-system support and a controlled benchmark justify a change. Validate startup and recovery on the exact kernel and file system.
OLAP	Large allocations or bulk I/O can make file_extend_method visible, but platform capability is the first gate. Benchmark on production-equivalent storage and include failure/fallback behavior.
Small nodes	Avoid nondefault file_extend_method on a small or heterogeneous fleet unless it solves a verified platform issue. Portability and reliable startup usually outweigh a speculative gain.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG16–19 Beta 3 unmodified; OLAP: PG16–19 Beta 3 unmodified; CRIT: PG16–19 Beta 3 unmodified; TINY: PG16–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Changing file_extend_method without applying its documented unit and configuration context.
Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
Assuming a configured value guarantees operating-system or storage behavior.
Failing to retest startup, failover, and workload latency after the change.

file_copy_method · backend_flush_after · checkpoint_flush_after · wal_sync_method