huge_pages_status

Definition PG 18 manual

Reports the state of huge pages in the current instance: on, off, or unknown (if displayed with postgres -C). This parameter is useful to determine whether allocation of huge pages was successful under huge_pages=try. See huge_pages for more information.

How it works

Reports whether the main shared-memory area actually uses explicit huge pages. It is an internal, read-only startup result with values off, on, or unknown.

The result is derived after applying huge_pages and attempting startup allocation against operating-system support and the available huge-page pool. It is not fixed by the PostgreSQL binary or initdb.

Use shared_memory_size_in_huge_pages to estimate the required pool and compare huge_pages_status with the requested huge_pages policy after every restart. Transparent Huge Pages are a separate operating-system mechanism.

Operational considerations

Trying to SET a read-only startup result.

Confusing huge_pages_status with the configured huge_pages request.

Ignoring a too-small operating-system huge-page pool or startup allocation failure.

Confusing explicit PostgreSQL huge pages with Transparent Huge Pages.

Assuming a status from one node applies to failover nodes with different OS configuration.

Workload guidance

OLAP: Large shared memory can need many huge pages. Reserve the pool with headroom for the real shared_memory_size and verify NUMA placement and restart behavior on each node.

OLTP: Not tunable directly. If on was requested but status is off, check huge_pages policy, OS support, pool size, permissions, and startup logs; resize the OS pool before restarting.

SMALL: Keep huge_pages=try unless the platform policy says otherwise. Do not reserve a large OS huge-page pool merely to make the status on for a small shared-memory area.