MIME-Version: 1.0
References: <19506-9478f3012ecc2328@postgresql.org>
 <CAJTYsWXftZbLOd=f7kGWA6xP6tC7neeP82PCtui=b9Rwv1Z3uA@mail.gmail.com>
In-Reply-To: 
 <CAJTYsWXftZbLOd=f7kGWA6xP6tC7neeP82PCtui=b9Rwv1Z3uA@mail.gmail.com>
From: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Date: Fri, 5 Jun 2026 14:34:27 +1000
Message-ID: 
 <CA+VUV5rWuhJsP7Q5nE=5XRp0701jQkDFaU26vamwoPq3sbq16Q@mail.gmail.com>
Subject: Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores
 dynamic_library_path with extension_control_path
To: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Cc: gabriele.bartolini@gmail.com, pgsql-bugs@lists.postgresql.org,
	Peter Eisentraut <peter@eisentraut.org>
Content-Type: multipart/alternative; boundary="000000000000b6b6c706537a2df4"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BVUV5rWuhJsP7Q5nE%3D5XRp0701jQkDFaU26vamwoPq3sbq16Q%40mail.gmail.com>
Precedence: bulk

--000000000000b6b6c706537a2df4
Content-Type: text/plain; charset="UTF-8"

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.slg01@gmail.com>
wrote:

> Hi,
>
> On Thu, 4 Jun 2026 at 21:23, PG Bug reporting form <noreply@postgresql.org>
> 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.
>>
>> 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

--000000000000b6b6c706537a2df4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Ayush,<br><br>I was about to draft an email to hackers =
about this. I had already done a patch:=C2=A0<a href=3D"https://github.com/=
gbartolini/postgres/pull/1">https://github.com/gbartolini/postgres/pull/1</=
a><div><br></div><div>Thanks for your reply. I will verify yours later.</di=
v><div><br></div><div>Cheers,</div><div>Gabriele</div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Fri, 5 Jun 2026 at 14:27, Ayush Tiwari &lt;<a href=3D"mailto:ayushtiwa=
ri.slg01@gmail.com">ayushtiwari.slg01@gmail.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D=
"ltr">Hi,</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Thu, 4 Jun 2026 at 21:23, PG Bug reporting form &lt;<a href=3D"=
mailto:noreply@postgresql.org" target=3D"_blank">noreply@postgresql.org</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The =
following bug has been logged on the website:<br>
<br>
Bug reference:=C2=A0 =C2=A0 =C2=A0 19506<br>
Logged by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gabriele Bartolini<br>
Email address:=C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:gabriele.bartolini@gma=
il.com" target=3D"_blank">gabriele.bartolini@gmail.com</a><br>
PostgreSQL version: 18.4<br>
Operating system:=C2=A0 =C2=A0Linux (reproduced under CloudNativePG/Kuberne=
tes)<br>
Description:=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br>
<br>
When an extension is installed in a location reached via<br>
`extension_control_path` / `dynamic_library_path` (rather than the<br>
compiled-in package library directory), a LOAD &#39;$libdir/foo&#39; hardco=
ded<br>
inside an extension&#39;s SQL script fails to find the library. PostGIS doe=
s<br>
this in its upgrade scripts, so a PostGIS upgrade fails:<br>
<br>
```<br>
app=3D# SELECT postgis_extensions_upgrade();<br>
NOTICE:=C2=A0 Updating extension postgis 3.6.1<br>
ERROR:=C2=A0 could not access file &quot;$libdir/postgis-3&quot;: No such f=
ile or directory<br>
CONTEXT:=C2=A0 SQL statement &quot;LOAD &#39;$libdir/postgis-3&#39;&quot;<b=
r>
extension script file &quot;postgis--ANY--3.6.3.sql&quot;, near line 1530<b=
r>
```<br>
<br>
This is a side effect of the fix for bug #18920 (commit f777d773878). Commi=
t<br>
4f7f7b03758 (`extension_control_path`) made the feature work by stripping<b=
r>
the &#39;$libdir/&#39; prefix so that dynamic_library_path is consulted. #1=
8920 then<br>
restricted that stripping to the function-load path so that a user-issued<b=
r>
`LOAD` keeps the literal &#39;$libdir/&#39; prefix. As a result, a `LOAD` i=
nside an<br>
extension script now also keeps the literal prefix, so<br>
`dynamic_library_path` is never consulted, and the library cannot be found.=
<br>
<br>
A `LOAD` running inside an extension script should behave like the<br>
extension&#39;s function loads (strip &#39;$libdir/&#39;), while a LOAD iss=
ued directly<br>
by a user should keep it (the #18920 behaviour). The two can be<br>
distinguished by `creating_extension`.<br>
<br>
Reproduced with the CloudNativePG operator on Kubernetes, but it applies to=
<br>
any setup using `extension_control_path` / `dynamic_library_path`.<br></blo=
ckquote><div><br></div>Thanks for the report and the very clear diagnosis, =
I could<br>reproduce the issue and your analysis matches what I see.<br><br=
>The attached patch implements exactly what you suggested: a<br>LOAD runnin=
g while creating_extension is true strips the simple<br>&quot;$libdir/&quot=
; prefix (so dynamic_library_path is consulted, like<br>the extension&#39;s=
 own function loads do), while a user-issued<br>LOAD keeps the literal pref=
ix and therefore preserves the<br>#18920 behaviour.<br><br>To avoid duplica=
ting the existing prefix-stripping logic in<br>load_external_function(), I =
factored it out into a small<br>static helper and reused it from load_file(=
).=C2=A0 Nested paths<br>(e.g. &quot;$libdir/foo/bar&quot;) are still left =
untouched and continue<br>to be expanded by expand_dynamic_library_name() a=
s before.<br><br>Verified locally that the PostGIS-style reproducer now suc=
ceeds<br>when the extension is installed via extension_control_path /<br>dy=
namic_library_path, that a plain user-issued<br>LOAD &#39;$libdir/foo&#39; =
still behaves as on HEAD, and that the<br>existing extension regression sui=
tes still pass.<br><br>Regards,<br><div>Ayush</div></div></div>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div>Gabriele Bartolini</div><div>VP, Chief Arch=
itect, Kubernetes</div><div><a href=3D"http://enterprisedb.com" target=3D"_=
blank">enterprisedb.com</a>=C2=A0/ Melbourne, Australia</div></div></div>

--000000000000b6b6c706537a2df4--