Thread: PG 14.1 psql: symbol lookup error: psql: undefined symbol: PQmblenBounded

New installation of PG-14.1 from tarball on RH 8.3 built with gcc-11
using CFLAGS='-O2 -march=native -pipe' (didn't seem particularly
exotic). Sample session is shown below, error appears to happen
more-or-less randomly: using "\l+" or "\db+" has caused it a few
times. Restarting the psql session and re-issuing the same commands
does not cause a repeatable error.

No errors show up in the logs -- it just repeats the

# cat postgresql-14*
2021-11-22 10:24:10.108 EST [3216099] LOG:  starting PostgreSQL 14.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
10.2.120201112 (Red Hat 10.2.1-8), 64-bit 
2021-11-22 10:24:10.108 EST [3216099] LOG:  listening on IPv4 address "127.0.0.1", port 5433
2021-11-22 10:24:10.109 EST [3216099] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5433"
2021-11-22 10:24:10.113 EST [3216101] LOG:  database system was shut down at 2021-11-22 10:24:03 EST
2021-11-22 10:24:10.117 EST [3216099] LOG:  database system is ready to accept connections

$ cat /etc/*release
NAME="Red Hat Enterprise Linux"
VERSION="8.3 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.3"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.3 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8.3:GA"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_BUGZILLA_PRODUCT_VERSION=8.3
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.3"
Red Hat Enterprise Linux release 8.3 (Ootpa)
Red Hat Enterprise Linux release 8.3 (Ootpa)

$ PGDATABASE=postgres PGUSER=postgres PGPORT=5433 PGHOST=localhost psql -a
\i 00-dbname.psql
\echo

\echo Current database: :"DBNAME"
Current database: "postgres"
\set etl_role :DBNAME '_etl'
\set qry_role :DBNAME '_qry'
\echo

\echo Loading database: :"DBNAME" as :"etl_role";
Loading database: "postgres" as "postgres_etl";
\set search_path log_data, loader_detail, calendar, audit, public
set role :etl_role;
psql:00-dbname.psql:13: ERROR:  role "postgres_etl" does not exist
set search_path to :search_path;
SET
psql (14.1)
Type "help" for help.

(cmd)postgres=# \set VERBOSITY verbose
(ins)postgres=# \set ECHO all
(ins)postgres=# \h create database
Command:     CREATE DATABASE
Description: create a new database
Syntax:
CREATE DATABASE name
    [ [ WITH ] [ OWNER [=] user_name ]
           [ TEMPLATE [=] template ]
           [ ENCODING [=] encoding ]
           [ LOCALE [=] locale ]
           [ LC_COLLATE [=] lc_collate ]
           [ LC_CTYPE [=] lc_ctype ]
           [ TABLESPACE [=] tablespace_name ]
           [ ALLOW_CONNECTIONS [=] allowconn ]
           [ CONNECTION LIMIT [=] connlimit ]
           [ IS_TEMPLATE [=] istemplate ] ]

URL: https://www.postgresql.org/docs/14/sql-createdatabase.html

(ins)postgres=# \connect cmod_log cmod_log
psql: symbol lookup error: psql: undefined symbol: PQmblenBounded

This message and any attachments are intended only for the use of the addressee and may contain information that is
privilegedand confidential. If the reader of the message is not the intended recipient or an authorized representative
ofthe intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited.
Ifyou have received this communication in error, please notify us immediately by e-mail and delete the message and any
attachmentsfrom your system. 

"Lembark, Steven" <Steven.Lembark@broadridge.com> writes:
> New installation of PG-14.1 from tarball on RH 8.3 built with gcc-11
> using CFLAGS='-O2 -march=native -pipe' (didn't seem particularly 
> exotic). Sample session is shown below, error appears to happen 
> more-or-less randomly: using "\l+" or "\db+" has caused it a few 
> times. Restarting the psql session and re-issuing the same commands
> does not cause a repeatable error. 

Hmph.  PQmblenBounded is exported by recent versions of libpq.so,
so this would seem to be telling us that psql is sometimes binding
to an older libpq.so.  Most likely the older one is in /usr/lib64
or some other standard place while you dropped the newer one someplace
else.  That's not a usage that Linux is terribly friendly to; you
have to be sure that the executable includes an rpath option pointing
to "someplace else", or that you consistently set the LD_LIBRARY_PATH
environment variable.  The fact that the failure is inconsistent
seems odd, so I'm not sure quite which way it's going wrong for you.

            regards, tom lane