public inbox for [email protected]
help / color / mirror / Atom feedFrom: Matheus Alcantara <[email protected]>
To: [email protected]
To: [email protected]
To: PG Bug reporting form <[email protected]>
Subject: Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path
Date: Fri, 5 Jun 2026 09:12:37 -0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
On 03/06/26 19:21, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19506
> Logged by: Gabriele Bartolini
> Email address: [email protected]
> PostgreSQL version: 18.4
> Operating system: Linux (reproduced under CloudNativePG/Kubernetes)
> Description:
>
> When an extension is installed in a location reached via
> `extension_control_path` / `dynamic_library_path` (rather than the
> compiled-in package library directory), a LOAD '$libdir/foo' hardcoded
> inside an extension's SQL script fails to find the library. PostGIS does
> this in its upgrade scripts, so a PostGIS upgrade fails:
>
> ```
> app=# SELECT postgis_extensions_upgrade();
> NOTICE: Updating extension postgis 3.6.1
> ERROR: could not access file "$libdir/postgis-3": No such file or directory
> CONTEXT: SQL statement "LOAD '$libdir/postgis-3'"
> extension script file "postgis--ANY--3.6.3.sql", near line 1530
> ```
>
> This is a side effect of the fix for bug #18920 (commit f777d773878). Commit
> 4f7f7b03758 (`extension_control_path`) made the feature work by stripping
> the '$libdir/' prefix so that dynamic_library_path is consulted. #18920 then
> restricted that stripping to the function-load path so that a user-issued
> `LOAD` keeps the literal '$libdir/' prefix. As a result, a `LOAD` inside an
> extension script now also keeps the literal prefix, so
> `dynamic_library_path` is never consulted, and the library cannot be found.
>
The only reason that it was decided that we should strip the $libdir
was that almost all popular extensions use $libdir prefix on
module_pathname on .control files, so the extension_control_path would
not work and waiting for extensions to change this will make the
extension_control_path almost useless (I hope that we can remove this
in the future once 18 is the minimum supported version).
I'm not sure if we also want this for the LOAD command, I'm wondering
if the postgis could remove the $libdir prefix from the LOAD command
instead of Postgres striping this, what do you think? IIRC a simple
LOAD 'postgis-3' on versions before 18 will still works.
I think that extensions should start to remove the $libdir prefix
since extension_control_path is going to the second release cycle, but
I agree that it seems more complicated than it actually is.
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
view thread (6+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox