huge_pages_status

huge_pages_status indicates the status of huge pages. It is read-only metadata in PG17–18, not a runtime tuning control.

Note

Fact — official short description: “Indicates the status of huge pages.”

Identity

Type , Valueenum: Upstream pg_settings type
Context , Valueinternal: Internal/preset and not user-settable
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Valueoff, on, unknown: — for non-enum types
Category , ValuePreset Options: Upstream classification
Latest boot value , Valueunknown: unknown

Lifecycle

Fact	Value
First observed	PG17
Present in	PG17–19 Beta 3
Removed in	No
Introduction commit	`a14354cac0e3` — Add GUC parameter “huge_pages_status”
Commit date	2023-07-06
Discussion	thread 1

Default history

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

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.

Tuning advice

Tip

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

Workload	Guidance
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.
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.
Small nodes	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.

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

Common pitfalls

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.

huge_pages · shared_memory_size_in_huge_pages · shared_memory_size · shared_buffers · min_dynamic_shared_memory · dynamic_shared_memory_type