shared_memory_type

shared_memory_type — Selects the shared memory implementation used for the main shared memory region. Observed in PG12–19 Beta 3; its last measured boot default is mmap 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: “Selects the shared memory implementation used for the main shared memory region.”

Identity

Type , Valueenum: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Valuesysv, mmap: — for non-enum types
Category , ValueResource Usage / Memory: Upstream classification
Latest boot value , Valuemmap: mmap

Lifecycle

Fact	Value
First observed	PG12
Present in	PG12–19 Beta 3
Removed in	No
Introduction commit	`f1bebef60ec8` — Add shared_memory_type GUC.
Commit date	2019-02-03
Discussion	thread 1 · thread 2

Default history

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

How it works

shared_memory_type selects the operating-system mechanism for PostgreSQL’s main shared-memory region, including shared_buffers and other fixed shared state. It does not set the region’s size.

Supported enum values and the first-supported boot default are platform dependent. The Docker/Linux catalog reports mmap; Windows has its own implementation, and sysv can require nondefault kernel limits for large allocations.

On Linux, explicit huge_pages support requires mmap. This parameter is distinct from dynamic_shared_memory_type, which governs temporary dynamic segments used by parallel query and extensions. 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	Keep the first supported platform default; on Linux that is normally mmap and is required for PostgreSQL’s explicit huge-page support. Use sysv only for a verified compatibility need and provision its kernel limits before restart.
OLAP	Large shared_buffers increases the importance of reliable main-region allocation, but workload label does not select the API. Validate startup, huge pages, failover, and service limits on the target operating system rather than benchmarking storage throughput.
Small nodes	Keep the platform default. Changing the implementation does not reduce the configured shared-memory size and can add kernel-limit or portability failures.

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

Common pitfalls

Treating the Linux-Docker mmap boot value as a portable default for every operating system.
Selecting sysv without raising the System V shared-memory kernel limits needed for the main region.
Forgetting that explicit huge pages on Linux require shared_memory_type=mmap.
Expecting the parameter to resize shared_buffers or other shared allocations.

dynamic_shared_memory_type · shared_buffers · huge_pages · huge_page_size · min_dynamic_shared_memory