dynamic_shared_memory_type

dynamic_shared_memory_type — Selects the dynamic shared memory implementation used. Observed in PG9.4–19 Beta 3; its last measured boot default is posix 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 dynamic shared memory implementation used.”

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 , Valueposix, sysv, mmap: — for non-enum types
Category , ValueResource Usage / Memory: Upstream classification
Latest boot value , Valueposix: posix

Lifecycle

Fact	Value
First observed	PG9.4
Present in	PG9.4–19 Beta 3
Removed in	No
Introduction commit	`0ac5e5a7e152` — Allow dynamic allocation of shared memory segments.
Commit date	2013-10-09
Discussion	—

Default history

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

How it works

dynamic_shared_memory_type selects how PostgreSQL creates dynamic shared memory segments used by parallel query and extensions: POSIX, System V, Windows, or file-backed mmap where supported.

The available enum values and selected boot default are platform dependent. The Docker/Linux catalog reports posix; that is not a portable promise for Windows or systems lacking POSIX shared memory.

The mmap implementation stores mapped files under pg_dynshmem and is generally discouraged because dirty pages may be written repeatedly. min_dynamic_shared_memory can preallocate part of parallel-query memory in the main shared region. 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 platform’s first supported default, normally posix on the measured Linux images. Change only to solve an API availability or diagnostic requirement, and restart-test parallel query plus extension workers on the target OS.
OLAP	Parallel queries use dynamic segments heavily, but choose the implementation by OS support and allocation behavior, not scan throughput alone. Avoid file-backed mmap on ordinary disk because repeated writeback can add I/O; a RAM disk is a special diagnostic case.
Small nodes	Keep the platform default. sysv may need kernel tuning, and file-backed mmap can turn memory traffic into disk I/O; neither is a free way to reduce memory use.

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

Common pitfalls

Treating the Linux-Docker posix boot value as portable to platforms without POSIX shared memory.
Using file-backed mmap on ordinary storage and creating repeated dirty-page writeback.
Selecting sysv without checking System V segment limits.
Confusing dynamic segments with the main region selected by shared_memory_type.
Changing the startup setting without testing parallel queries and extensions that allocate DSM.

shared_memory_type · min_dynamic_shared_memory · max_parallel_workers · max_worker_processes · huge_pages