extension_destdir

Definition PG 17 manual

No dedicated definition was found in this manual. The parameter’s presence and values come from the metadata snapshot identified above.

How it works

The version matrix proves that extension_destdir is exposed by the measured Debian/PGDG binaries from PG9.5 through PG17. An exhaustive upstream GUC-source pickaxe has no introduction commit because the name comes from Debian's extension_destdir package patch, not the PostgreSQL source tree.

The patch prepends a DESTDIR-like staging root when the server locates extension control and SQL files and the modules behind functions. Debian's pg_virtualenv uses it to test a package before its files are installed in their final system paths; it was explicitly a packaging and build-time facility, not a general production extension search path.

From PostgreSQL 18, use the upstream extension_control_path for control and SQL files together with dynamic_library_path for shared libraries, or install the extension in standard locations. Remove extension_destdir from every config file, ALTER SYSTEM layer, role/database setting, and generated template before starting the newer server.

Operational considerations

Calling extension_destdir an upstream PostgreSQL parameter or assigning it an upstream introduction commit.

Continuing to emit the downstream name on PostgreSQL 18 or later, where the measured packages no longer recognize it.

Migrating extension control files but forgetting the shared-library half of the path design.

Testing as a build user while the database service account cannot read the final directories, files, or parent paths.

Workload guidance

OLAP: Apply the same migration to ETL and analytical extension stacks, including worker processes and standbys. Rehearse CREATE EXTENSION, ALTER EXTENSION UPDATE, restore, and failover with the final filesystem layout.

OLTP: Treat this as downstream migration debt, not a tuning control. Package extensions in supported locations, test extension_control_path and dynamic_library_path under the service account, and remove the obsolete key before the PostgreSQL 18 upgrade.

SMALL: Prefer standard package locations. A one-node system gains little from recreating a Debian build-time staging mechanism, while an unknown GUC can prevent a modern server from starting.