Horton

Thread

Commits

  1. Fix pg_upgrade failure when extension_control_path is used

  1. pg_upgrade fails when extension_control_path is used

    Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> — 2026-03-03T08:15:43Z

    Hello

The upgrade process from 18 to 19devel using `extension_control_path`
fails due to some extensions having the `$libdir/` string hard coded in
the `module_pathname`.

The finding was done by Niccolo Fei while working on the images
extension in CloudNativePG, this feature relies on the
`extension_control_path` GUC that was included in PostgreSQL 18 to
allow having extension in small images. This is done by having a
directory layer with two main paths, one for the extension `.sql` and
`.control` files, and another for the `.so` files or any file that
requires to be added into the `dynamic_library_path`. These two things
trigger the bug during the upgrade.

The problem may look simple and like it can be reproduced with any lib
that is added to the `dynamic_library_path`, but the problem is due to
`pg_upgrade`. Using the `probin` field from `pg_catalog.pg_proc` as the
string used to pass to the `LOAD` instruction when loading the
extension again during the upgrade process gives the following error:

could not load library "$libdir/test_ext": ERROR:  could not access
file "$libdir/test_ext": No such file or directory

This problem was already difficult to explain so I decided to create a
test for this, and the error above is the result of the test without
the patch to the `function.c` file.

The patch uses pretty much the same technique that was used in the
`extenion_control_path` patch, that it removes the `$libdir/` string
when the name of the extension is required.

The implementation of the test is something that I would like to get
help on, I moved the location a couple of times to arrive to this one
because it didn't fit in any other place. Also, it makes it easier to
implement the `make` support for it, but I'm still having doubts if
it's the right place.

I'm attaching the patch with the fix and also with the test for it.

Thanks everyone for the reviews!


-- 
Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
EnterpriseDB

  2. Re: pg_upgrade fails when extension_control_path is used

    Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> — 2026-03-05T11:36:36Z

    Hello,

I'm attaching a v2 with rebase and adding Niccolo Fei as one of the
reviewers.

Thank you!


-- 
Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
EnterpriseDB

  3. Re: pg_upgrade fails when extension_control_path is used

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-03-05T15:12:14Z

    Hi,

On 03/03/26 05:15, Jonathan Gonzalez V. wrote:
> The upgrade process from 18 to 19devel using `extension_control_path`
> fails due to some extensions having the `$libdir/` string hard coded in
> the `module_pathname`.
> 
> The finding was done by Niccolo Fei while working on the images
> extension in CloudNativePG, this feature relies on the
> `extension_control_path` GUC that was included in PostgreSQL 18 to
> allow having extension in small images. This is done by having a
> directory layer with two main paths, one for the extension `.sql` and
> `.control` files, and another for the `.so` files or any file that
> requires to be added into the `dynamic_library_path`. These two things
> trigger the bug during the upgrade.
> 

> The problem may look simple and like it can be reproduced with any lib
> that is added to the `dynamic_library_path`,

What do you mean by this? Manually executing LOAD '$libdir/foo' will 
fail if the lib "foo" does not exists on $libdir and this is an 
expected behavior since the user is forcing to load the lib from 
$libdir path. If user execute LOAD 'foo' it will search on 
dynamic_library_path along with extension_control_path. See the commit 
message of f777d773878.

> but the problem is due to
> `pg_upgrade`. Using the `probin` field from `pg_catalog.pg_proc` as the
> string used to pass to the `LOAD` instruction when loading the
> extension again during the upgrade process gives the following error:
> 
> could not load library "$libdir/test_ext": ERROR:  could not access
> file "$libdir/test_ext": No such file or directory
> 
> This problem was already difficult to explain so I decided to create a
> test for this, and the error above is the result of the test without
> the patch to the `function.c` file.
> 
> The patch uses pretty much the same technique that was used in the
> `extenion_control_path` patch, that it removes the `$libdir/` string
> when the name of the extension is required.
> 

I was not fully happy with the strip hack on extension_control_path on 
the time and I have the same felling here but I don't think that we 
have another way to fix this issue, at lest I couldn't think it.

The patch seems correct to me because we don't want to have this on 
LOAD command itself since the user may want to load an extension from 
$libdir so the strip logic on pg_upgrade is more appropriate.

I'm wondering if we need to handle nested paths on pg_upgrade in the 
same way that we handle on load_external_function(), I think that is 
not needed but it can be good to double check.

One minor comment is that the code comment on function.c can be 
similar to what we have on load_external_function():

  /*
  * For extensions with hardcoded '$libdir/' library names, we
  * strip the prefix to allow the library search path to be used.
  */

> The implementation of the test is something that I would like to get
> help on, I moved the location a couple of times to arrive to this one
> because it didn't fit in any other place. Also, it makes it easier to
> implement the `make` support for it, but I'm still having doubts if
> it's the right place.
> 

I personally don't see any issue on keeping the new TAP test on 
pg_upgrade/t with the other ones since this issue is related with 
pg_upgrade itself, but others can have other opinions on this.

> I'm attaching the patch with the fix and also with the test for it.
> 

Thanks for reporting this and for sharing the patch.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

  4. Re: pg_upgrade fails when extension_control_path is used

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-03-05T15:16:41Z

    On 05/03/26 08:36, Jonathan Gonzalez V. wrote:
> Hello,
> 
> I'm attaching a v2 with rebase and adding Niccolo Fei as one of the
> reviewers.
> 
> Thank you!
> 
> 

I've just saw your v2 after I've sent my review comments over v1 version.

I quickly check the v2 and it seems that the only change compared with 
v1 is on commit message, so I think that my comments on [1] still applies.

Thanks for the new version and sorry for the confusion.

[1] 
https://www.postgresql.org/message-id/984363e5-5f3f-4018-9f9e-c27406848151%40gmail.com

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

  5. Re: pg_upgrade fails when extension_control_path is used

    Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> — 2026-03-06T12:10:12Z

    Hello!

>  that the code comment on function.c can be 
> similar to what we have on load_external_function():
> 
>   /*
>   * For extensions with hardcoded '$libdir/' library names, we
>   * strip the prefix to allow the library search path to be used.
>   */
> 
> > 
I'm attaching a v3 with an improved messages

Also updated the reviewers list on the message

Regards!
> 
-- 
Jonathan Gonzalez V. <jonathan.abdiel@gmail.com>
EnterpriseDB

  6. Re: pg_upgrade fails when extension_control_path is used

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-03-09T20:49:35Z

    On 06/03/26 09:10, Jonathan Gonzalez V. wrote:
> Hello!
> 
>>   that the code comment on function.c can be
>> similar to what we have on load_external_function():
>>
>>    /*
>>    * For extensions with hardcoded '$libdir/' library names, we
>>    * strip the prefix to allow the library search path to be used.
>>    */
>>
>>>
> I'm attaching a v3 with an improved messages
> 
> Also updated the reviewers list on the message
> 

Thanks for updating the patch, it looks good to me and fix the 
described issue.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

  7. Re: pg_upgrade fails when extension_control_path is used

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-16T10:57:14Z

    On 09.03.26 21:49, Matheus Alcantara wrote:
> On 06/03/26 09:10, Jonathan Gonzalez V. wrote:
>> Hello!
>>
>>>   that the code comment on function.c can be
>>> similar to what we have on load_external_function():
>>>
>>>    /*
>>>    * For extensions with hardcoded '$libdir/' library names, we
>>>    * strip the prefix to allow the library search path to be used.
>>>    */
>>>
>>>>
>> I'm attaching a v3 with an improved messages
>>
>> Also updated the reviewers list on the message
>>
> 
> Thanks for updating the patch, it looks good to me and fix the described 
> issue.

committed