dynamic_library_path

dynamic_library_path is the PostgreSQL setting that defines the path for dynamically loadable modules.

Note

Fact — official short description: “Sets the path for dynamically loadable modules.”

Identity

Type , Valuestring: Upstream pg_settings type
Context , Valuesuperuser: Settable at runtime by a superuser
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueClient Connection Defaults / Other Defaults: Upstream classification
Latest boot value , Value$libdir: $libdir

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

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

How it works

dynamic_library_path sets the path for dynamically loadable modules. If a dynamically loadable module needs to be opened and the specified name does not have a directory component (i.e., the name does not contain a slash), the system will search this path for the specified file. The search is used only for module names without a directory component; $libdir points at PostgreSQL’s version-specific library directory.

dynamic_library_path is a SUPERUSER-context setting. Superuser or a role granted the appropriate SET privilege can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

Library discovery and preloading interact with installed binary versions, extension control files, server or backend startup, and the module’s own GUCs.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Keep dynamic_library_path restricted to administrator-controlled, version-matched directories and retain $libdir. Use absolute module paths only when deployment and rollback manage them explicitly.
OLAP	Add a search directory only for a reviewed analytical extension package present identically on every failover target.
Small nodes	Keep $libdir. Expanding the native-code search path provides no capacity gain and increases packaging and trust risk.

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

Common pitfalls

Changing dynamic_library_path in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.
Naming a missing or ABI-incompatible module and causing connection failure or a server that cannot start.
Treating a search or preload path as harmless even though it defines which native code the server trusts.
Changing dynamic_library_path globally without a rollback plan and a client or operational compatibility test.

shared_preload_libraries · session_preload_libraries · local_preload_libraries · jit_provider · extension_control_path