max_files_per_process

Definition PG 18 manual

Sets the maximum number of open files each server subprocess is allowed to open simultaneously; files already opened in the postmaster are not counted toward this limit. The default is one thousand files.

If the kernel is enforcing a safe per-process limit, you don't need to worry about this setting. But on some platforms (notably, most BSD systems), the kernel will allow individual processes to open many more files than the system can actually support if many processes all try to open that many files. If you find yourself seeing “Too many open files” failures, try reducing this setting. This parameter can only be set at server start.

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.

Operational considerations

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.

Workload guidance

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.

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.

SMALL: 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.