| From: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com> |
|---|---|
| To: | gabriele(dot)bartolini(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, PG Bug reporting form <noreply(at)postgresql(dot)org> |
| Subject: | Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path |
| Date: | 2026-06-05 12:12:37 |
| Message-ID: | 9ef850b9-d127-44db-9a6c-4db64436b056@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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: gabriele(dot)bartolini(at)gmail(dot)com
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dag Lem | 2026-06-05 12:35:12 | Re: REINDEX (CONCURRENTLY) TABLE handles DEFERRED constraints as IMMEDIATE while processing |
| Previous Message | Dag Lem | 2026-06-05 11:25:52 | REINDEX (CONCURRENTLY) TABLE handles DEFERRED constraints as IMMEDIATE while processing |