# 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 {#identity}

| Field | Value | Meaning |
| --- | --- | --- |
| Type | `integer` | Upstream pg_settings type |
| Context | `postmaster` | Requires a server restart |
| Unit | — | Raw unit |
| Range | `64` – `2147483647` | Raw limits in the last observed version |
| Enum values | — | — for non-enum types |
| Category | Resource Usage / Kernel Resources | Upstream classification |
| Latest boot value | `1000` | 1000 |
{.fields meta="-"}

## Lifecycle {#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 {#default-history}

| Versions | Raw `boot_val` | Unit | Human value |
| --- | --- | --- | --- |
| PG9.0–19 Beta 3 | `1000` | — | 1000 |
{.full-width caption="Measured PG9.0–19 Beta 3 boot defaults"}

## How it works {#mechanism}

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 {#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. |
{.full-width}

## Pigsty {#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 | — | — |
{.full-width}

> [!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 {#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.

## Related parameters {#related-parameters}

[`max_connections`](/parameters/max-connections/) · [`max_worker_processes`](/parameters/max-worker-processes/) · [`max_wal_senders`](/parameters/max-wal-senders/) · [`shared_preload_libraries`](/parameters/shared-preload-libraries/)

## References {#references}

- [PostgreSQL 19 Beta 3 — max_files_per_process](https://www.postgresql.org/docs/19/runtime-config-resource.html#GUC-MAX-FILES-PER-PROCESS)
- [PostgreSQL 19 release notes](https://www.postgresql.org/docs/19/release-19.html)
- [Machine-readable GUC export](/data/guc.jsonl)