BUG #19518: Path resolution for loading a function fails, if postgres is somewhere in the path.

Started by PG Bug reporting form11 days ago2 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 19518
Logged by: Clemens Ruck
Email address: clemens.ruck@t-online.de
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.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: PG Bug reporting form (#1)
Re: BUG #19518: Path resolution for loading a function fails, if postgres is somewhere in the path.

PG Bug reporting form <noreply@postgresql.org> 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