max_files_per_process

max_files_per_process — Sets the maximum number of files each server process is allowed to open simultaneously. Observed in PG9.0–19 Beta 3; its last measured boot default is 1000 in PG19 Beta 3, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Sets the maximum number of files each server process is allowed to open simultaneously.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value—: Raw unit
Range , Value64 – 2147483647: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueResource Usage / Kernel Resources: Upstream classification
Latest boot value , Value1000: 1000

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

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

How it works

max_files_per_process is PostgreSQL’s startup-time expectation for how many files one server subprocess may keep open, excluding files inherited already open from the postmaster.

It does not raise the kernel’s file-descriptor limit. PostgreSQL uses it in resource management, and on kernels that overcommit descriptors across processes a lower value can prevent system-wide exhaustion.

The relevant capacity is per process multiplied across backends and workers. ‘Too many open files’ can also require fixing OS service limits, connection counts, partition fan-out, or extension behavior. Its postmaster context fixes the value at server start; changing it requires a restart.

Tuning advice

Tip

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

Workload	Guidance
OLTP	First compare the PostgreSQL value with the service’s real per-process nofile limit and observed descriptor use. Raising this GUC cannot raise the kernel limit; on systems that overcommit descriptors across many processes, a lower PostgreSQL value can be safer.
OLAP	Large partition or index fan-out can increase descriptors in one backend, but size from measured peak opens and the aggregate backend/worker count. Resolve leaks and OS service limits before changing the PostgreSQL ceiling.
Small nodes	Keep the default unless descriptor evidence says otherwise. A small host can exhaust the system-wide file table even when every process remains below its individual limit.

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: PG9.0–19 Beta 3 unmodified; OLAP: PG9.0–19 Beta 3 unmodified; CRIT: PG9.0–19 Beta 3 unmodified; TINY: PG9.0–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Expecting the GUC to raise ulimit or the service manager’s nofile limit.
Sizing only per process and ignoring the aggregate across connections and workers.
Raising the value to hide a descriptor leak or excessive partition/index fan-out.
Forgetting that files inherited already open from the postmaster are excluded from this count.

max_connections · max_worker_processes · max_wal_senders · shared_preload_libraries