public inbox for [email protected]
help / color / mirror / Atom feedBUG #19518: Path resolution for loading a function fails, if postgres is somewhere in the path.
2+ messages / 2 participants
[nested] [flat]
* BUG #19518: Path resolution for loading a function fails, if postgres is somewhere in the path.
@ 2026-06-12 19:19 PG Bug reporting form <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2026-06-12 19:19 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
The following bug has been logged on the website:
Bug reference: 19518
Logged by: Clemens Ruck
Email address: [email protected]
PostgreSQL version: 17.4
Operating system: Ubuntu 24.04.04
Description:
I encountered an incorrect $libdir expansion when loading a C-language
function from a shared library.
My directory layout is:
/home/testuser/projects/hol-postgres/
install/bin/postgres
install/lib/
/home/testuser/projects/hol-lambdas/
src/ext/lambda_udfs.so
PostgreSQL was configured with:
./configure \
--prefix=/home/testuser/projects/hol-postgres/install \
--with-llvm
The following statement fails:
CREATE OR REPLACE FUNCTION test(integer)
RETURNS integer
AS '$libdir/../../../hol-lambdas/src/ext/l_udfs.so',
'l_test'
LANGUAGE C
STRICT;
The expected expansion is:
$libdir
= /home/testuser/projects/hol-postgres/install/lib
and therefore:
$libdir/../../../hol-lambdas/src/ext/lambda_udfs.so
= /home/testuser/projects/hol-lambdas/src/ext/lambda_udfs.so
That file exists and is readable by the PostgreSQL server process.
However, PostgreSQL resolves $libdir to an unexpected directory and reports
that the shared library cannot be found.
The issue depends on the surrounding directory names. With the PostgreSQL
repository located under a differently named directory, the same build and
SQL statement resolve the expected path.
The server binary and matching pg_config are used explicitly:
/home/testuser/projects/hol-postgres/install/bin/postgres
/home/testuser/projects/hol-postgres/install/bin/pg_config
and:
pg_config --pkglibdir
reports:
/home/testuser/projects/hol-postgres/install/lib
The relevant loading path appears to be:
src/backend/utils/fmgr/dfmgr.c
load_external_function()
expand_dynamic_library_name()
internal_load_library()
$libdir is expanded from pkglib_path. That path is initialized using:
get_pkglib_path(my_exec_path, pkglib_path)
which calls make_relative_path() in src/port/path.c.
I suspect that the relocatable-installation suffix matching in
make_relative_path() incorrectly recognizes part of the actual executable
path as the compiled-in PGBINDIR suffix, causing an incorrect relocated
PKGLIBDIR to be derived.
Expected behavior:
The running server should derive:
/home/testuser/projects/hol-postgres/install/lib
as pkglib_path, consistently with the matching pg_config --pkglibdir output.
Actual behavior:
The backend derives a different path, causing $libdir references in CREATE
FUNCTION ... LANGUAGE C to fail.
I can provide the exact compiled values of PGBINDIR and PKGLIBDIR, the
resulting runtime pkglib_path, and a patch or regression test if required.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #19518: Path resolution for loading a function fails, if postgres is somewhere in the path.
@ 2026-06-13 00:52 Tom Lane <[email protected]>
parent: PG Bug reporting form <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2026-06-13 00:52 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
PG Bug reporting form <[email protected]> writes:
> I encountered an incorrect $libdir expansion when loading a C-language
> function from a shared library.
I'm not sure if this is just a typo in your submission,
but:
> CREATE OR REPLACE FUNCTION test(integer)
> RETURNS integer
> AS '$libdir/../../../hol-lambdas/src/ext/l_udfs.so',
> 'l_test'
> LANGUAGE C
> STRICT;
This is looking for l_udfs.so, but the rest of your message
references lambda_udfs.so. That wouldn't be the cause would it?
> The issue depends on the surrounding directory names. With the PostgreSQL
> repository located under a differently named directory, the same build and
> SQL statement resolve the expected path.
The presence of "postgres" in the --prefix string affects whether
our Makefile.global decides to append an extra directory level to
pkglib_path:
pkglibdir = $(libdir)
ifeq "$(findstring pgsql, $(pkglibdir))" ""
ifeq "$(findstring postgres, $(pkglibdir))" ""
override pkglibdir := $(pkglibdir)/postgresql
endif
endif
That is, with your specified
--prefix=/home/testuser/projects/hol-postgres/install
the pkglib_path would be
/home/testuser/projects/hol-postgres/install/lib
but with, say,
--prefix=/home/testuser/projects/hol-postgrex/install
the pkglib_path would be
/home/testuser/projects/hol-postgrex/install/lib/postgresql
thus changing the number of ".."s needed in your example. Perhaps
that rule explains your results with different installation paths?
> I can provide the exact compiled values of PGBINDIR and PKGLIBDIR, the
> resulting runtime pkglib_path, and a patch or regression test if required.
I'm quite hesitant to change the behavior around this: it's stood for
decades and any change would certainly break a bunch of people's
build/install recipes.
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-06-13 00:52 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-12 19:19 BUG #19518: Path resolution for loading a function fails, if postgres is somewhere in the path. PG Bug reporting form <[email protected]>
2026-06-13 00:52 ` Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox