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