dynamic_shared_memory_type

Definition PG 18 manual

Specifies the dynamic shared memory implementation that the server should use. Possible values are posix (for POSIX shared memory allocated using shm_open), sysv (for System V shared memory allocated via shmget), windows (for Windows shared memory), and mmap (to simulate shared memory using memory-mapped files stored in the data directory). Not all values are supported on all platforms; the first supported option is usually the default for that platform. The use of the mmap option, which is not the default on any platform, is generally discouraged because the operating system may write modified pages back to disk repeatedly, increasing system I/O load; however, it may be useful for debugging, when the pg_dynshmem directory is stored on a RAM disk, or when other shared memory facilities are not available. This parameter can only be set at server start.

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.

Operational considerations

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.

Workload guidance

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.

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.

SMALL: 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.