MIME-Version: 1.0
References: <19506-9478f3012ecc2328@postgresql.org>
 <9ef850b9-d127-44db-9a6c-4db64436b056@gmail.com>
 <CA+VUV5r0Yu11PZrBa6yE4djSii3AHta7T57rza40fxyq6p8AOA@mail.gmail.com>
In-Reply-To: 
 <CA+VUV5r0Yu11PZrBa6yE4djSii3AHta7T57rza40fxyq6p8AOA@mail.gmail.com>
From: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Date: Tue, 7 Jul 2026 11:37:42 +1000
Message-ID: 
 <CA+VUV5oeJEMb=hrKLS9bhUN0VEv3zCHHUTAbOvDVbim0brwA2g@mail.gmail.com>
Subject: Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores
 dynamic_library_path with extension_control_path
To: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: gabriele.bartolini@gmail.com, pgsql-bugs@lists.postgresql.org,
	PG Bug reporting form <noreply@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000aebb8e0655fb70f0"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BVUV5oeJEMb%3DhrKLS9bhUN0VEv3zCHHUTAbOvDVbim0brwA2g%40mail.gmail.com>
Precedence: bulk

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

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

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

<div dir=3D"ltr">Hi Matheus, do you think we can apply this patch to the ne=
xt Postgres minor release?<div><br></div></div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 24 J=
un 2026 at 19:47, Gabriele Bartolini &lt;<a href=3D"mailto:gabriele.bartoli=
ni@enterprisedb.com">gabriele.bartolini@enterprisedb.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi=
 everyone,<div><br></div><div>I realised I hadn&#39;t sent this email with =
the patch. Please find the attached patch.</div><div><br>Thanks,</div><div>=
Gabriele</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Fri, 5 Jun 2026 at 22:12, Matheus Alcantara &lt;<a href=
=3D"mailto:matheusssilv97@gmail.com" target=3D"_blank">matheusssilv97@gmail=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">On 03/06/26 19:21, PG Bug reporting form wrote:<br>
&gt; The following bug has been logged on the website:<br>
&gt; <br>
&gt; Bug reference:=C2=A0 =C2=A0 =C2=A0 19506<br>
&gt; Logged by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gabriele Bartolini<br>
&gt; Email address:=C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:gabriele.bartolin=
i@gmail.com" target=3D"_blank">gabriele.bartolini@gmail.com</a><br>
&gt; PostgreSQL version: 18.4<br>
&gt; Operating system:=C2=A0 =C2=A0Linux (reproduced under CloudNativePG/Ku=
bernetes)<br>
&gt; Description:<br>
&gt; <br>
&gt; When an extension is installed in a location reached via<br>
&gt; `extension_control_path` / `dynamic_library_path` (rather than the<br>
&gt; compiled-in package library directory), a LOAD &#39;$libdir/foo&#39; h=
ardcoded<br>
&gt; inside an extension&#39;s SQL script fails to find the library. PostGI=
S does<br>
&gt; this in its upgrade scripts, so a PostGIS upgrade fails:<br>
&gt; <br>
&gt; ```<br>
&gt; app=3D# SELECT postgis_extensions_upgrade();<br>
&gt; NOTICE:=C2=A0 Updating extension postgis 3.6.1<br>
&gt; ERROR:=C2=A0 could not access file &quot;$libdir/postgis-3&quot;: No s=
uch file or directory<br>
&gt; CONTEXT:=C2=A0 SQL statement &quot;LOAD &#39;$libdir/postgis-3&#39;&qu=
ot;<br>
&gt; extension script file &quot;postgis--ANY--3.6.3.sql&quot;, near line 1=
530<br>
&gt; ```<br>
&gt; <br>
&gt; This is a side effect of the fix for bug #18920 (commit f777d773878). =
Commit<br>
&gt; 4f7f7b03758 (`extension_control_path`) made the feature work by stripp=
ing<br>
&gt; the &#39;$libdir/&#39; prefix so that dynamic_library_path is consulte=
d. #18920 then<br>
&gt; restricted that stripping to the function-load path so that a user-iss=
ued<br>
&gt; `LOAD` keeps the literal &#39;$libdir/&#39; prefix. As a result, a `LO=
AD` inside an<br>
&gt; extension script now also keeps the literal prefix, so<br>
&gt; `dynamic_library_path` is never consulted, and the library cannot be f=
ound.<br>
&gt; <br>
<br>
The only reason that it was decided that we should strip the $libdir <br>
was that almost all popular extensions use $libdir prefix on <br>
module_pathname on .control files, so the extension_control_path would <br>
not work and waiting for extensions to change this will make the <br>
extension_control_path almost useless (I hope that we can remove this <br>
in the future once 18 is the minimum supported version).<br>
<br>
I&#39;m not sure if we also want this for the LOAD command, I&#39;m wonderi=
ng <br>
if the postgis could remove the $libdir prefix from the LOAD command <br>
instead of Postgres striping this, what do you think? IIRC a simple <br>
LOAD &#39;postgis-3&#39; on versions before 18 will still works.<br>
<br>
I think that extensions should start to remove the $libdir prefix <br>
since extension_control_path is going to the second release cycle, but <br>
I agree that it seems more complicated than it actually is.<br>
<br>
--<br>
Matheus Alcantara<br>
EDB: <a href=3D"https://www.enterprisedb.com" rel=3D"noreferrer" target=3D"=
_blank">https://www.enterprisedb.com</a><br>
<br>
<br>
</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>
</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>

--000000000000aebb8e0655fb70f0--