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

Hi Ayush,

I was about to draft an email to hackers about this. I had already done a
patch: https://github.com/gbartolini/postgres/pull/1

Thanks for your reply. I will verify yours later.

Cheers,
Gabriele

On Fri, 5 Jun 2026 at 14:27, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
wrote:

> Hi,
>
> On Thu, 4 Jun 2026 at 21:23, PG Bug reporting form <noreply(at)postgresql(dot)org>
> 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.
>>
>> A `LOAD` running inside an extension script should behave like the
>> extension's function loads (strip '$libdir/'), while a LOAD issued
>> directly
>> by a user should keep it (the #18920 behaviour). The two can be
>> distinguished by `creating_extension`.
>>
>> Reproduced with the CloudNativePG operator on Kubernetes, but it applies
>> to
>> any setup using `extension_control_path` / `dynamic_library_path`.
>>
>
> Thanks for the report and the very clear diagnosis, I could
> reproduce the issue and your analysis matches what I see.
>
> The attached patch implements exactly what you suggested: a
> LOAD running while creating_extension is true strips the simple
> "$libdir/" prefix (so dynamic_library_path is consulted, like
> the extension's own function loads do), while a user-issued
> LOAD keeps the literal prefix and therefore preserves the
> #18920 behaviour.
>
> To avoid duplicating the existing prefix-stripping logic in
> load_external_function(), I factored it out into a small
> static helper and reused it from load_file(). Nested paths
> (e.g. "$libdir/foo/bar") are still left untouched and continue
> to be expanded by expand_dynamic_library_name() as before.
>
> Verified locally that the PostGIS-style reproducer now succeeds
> when the extension is installed via extension_control_path /
> dynamic_library_path, that a plain user-issued
> LOAD '$libdir/foo' still behaves as on HEAD, and that the
> existing extension regression suites still pass.
>
> Regards,
> Ayush
>

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