dynamic_library_path

Definition PG 18 manual

If a dynamically loadable module needs to be opened and the file name specified in the CREATE FUNCTION or LOAD command does not have a directory component (i.e., the name does not contain a slash), the system will search this path for the required file.

The value for dynamic_library_path must be a list of absolute directory paths separated by colons (or semi-colons on Windows). If a list element starts with the special string $libdir, the compiled-in PostgreSQL package library directory is substituted for $libdir; this is where the modules provided by the standard PostgreSQL distribution are installed. (Use pg_config --pkglibdir to find out the name of this directory.) For example:

dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'

or, in a Windows environment:

dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'

The default value for this parameter is '$libdir'. If the value is set to an empty string, the automatic path search is turned off.

This parameter can be changed at run time by superusers and users with the appropriate SET privilege, but a setting done that way will only persist until the end of the client connection, so this method should be reserved for development purposes. The recommended way to set this parameter is in the postgresql.conf configuration file.

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.

Operational considerations

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.

Workload guidance

OLAP: Add a search directory only for a reviewed analytical extension package present identically on every failover target.

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.

SMALL: Keep $libdir. Expanding the native-code search path provides no capacity gain and increases packaging and trust risk.