Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path

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(dot)bartolini(at)enterprisedb(dot)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(at)gmail(dot)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(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
>>
>>
>>
>
> --
> Gabriele Bartolini
> VP, Chief Architect, Kubernetes
> enterprisedb.com / Melbourne, Australia
>

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