Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path - Mailing list pgsql-bugs

From Gabriele Bartolini
Subject Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path
Date
Msg-id CA+VUV5oeJEMb=hrKLS9bhUN0VEv3zCHHUTAbOvDVbim0brwA2g@mail.gmail.com
Whole thread
In response to Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path  (Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>)
Responses Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path
List pgsql-bugs
Hi Matheus, do you think we can apply this patch to the next Postgres minor release?


On Wed, 24 Jun 2026 at 19:47, Gabriele Bartolini <gabriele.bartolini@enterprisedb.com> wrote:
Hi everyone,

I realised I hadn't sent this email with the patch. Please find the attached patch.

Thanks,
Gabriele

On Fri, 5 Jun 2026 at 22:12, Matheus Alcantara <matheusssilv97@gmail.com> wrote:
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.bartolini@gmail.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




--
Gabriele Bartolini
VP, Chief Architect, Kubernetes
enterprisedb.com / Melbourne, Australia


--
Gabriele Bartolini
VP, Chief Architect, Kubernetes
enterprisedb.com / Melbourne, Australia

pgsql-bugs by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: BUG #19519: REPACK can fail due to missing chunk for toast value
Next
From: Michael Paquier
Date:
Subject: Re: BUG #19519: REPACK can fail due to missing chunk for toast value