PG17beta1: Unable to test Postgres on Fedora due to fatal Error in psql: undefined symbol: PQsocketPoll - Mailing list pgsql-hackers
| From | Hans Buschmann |
|---|---|
| Subject | PG17beta1: Unable to test Postgres on Fedora due to fatal Error in psql: undefined symbol: PQsocketPoll |
| Date | |
| Msg-id | 6dbae6e635db43a0bbba21e09a47784e@nidsa.net Whole thread Raw |
| Responses |
Re: PG17beta1: Unable to test Postgres on Fedora due to fatal Error in psql: undefined symbol: PQsocketPoll
|
| List | pgsql-hackers |
- Problem and reproducability
After the release of PG17b1 I wanted to test it on a newly installed machine:
I installed Fedora 40 Server on x86-64 and did a full dnf update (as of 23.may 2024).
To self-compile from source I did:
sudo dnf group install "C Development*" "Development*"
sudo dnf install wine mold meson perl zstd lz4 lz4-devel libzstd-devel
(This may be a little too much, I was lazy for minimal installation)
I built Postgres 17 beta1 from source with meson and installed it with ninja install.
I started the server and created a new database with psql
I restored a test database from dump with pg_restore.
When I tried to connect to the restored database with psql \c I got:
[root@localhost local]# sudo -u postgres pgbeta/bin/psql -h /tmp -p 5431
psql (17beta1)
Type "help" for help.
postgres=# select version ();
version
--------------------------------------------------------------------
PostgreSQL 17beta1 on x86_64-linux, compiled by gcc-14.1.1, 64-bit
(1 row)
postgres=# \l
List of databases
Name | Owner | Encoding | Locale Provider | Collate | Ctype | Locale | ICU Rules | Access privileges
-----------+----------+----------+-----------------+---------+-------+--------+-----------+-----------------------
cpsdb | postgres | UTF8 | builtin | C | C | C | |
postgres | postgres | UTF8 | builtin | C | C | C | |
template0 | postgres | UTF8 | builtin | C | C | C | | =c/postgres +
| | | | | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | builtin | C | C | C | | =c/postgres +
| | | | | | | | postgres=CTc/postgres
(4 rows)
postgres=# \c cpsdb
pgbeta/bin/psql: symbol lookup error: pgbeta/bin/psql: undefined symbol: PQsocketPoll
[root@localhost local]#
----------------------------------------------------------------------- ERROR ^^^^^^^^^^^^^^^^^^^^^^
2. Analysis
(To my understanding) the problem comes from incompatible libpq.so libraries on the system.
The installation of all the development packages installed :
[root@localhost lib64]# dnf list installed libpq
Installed Packages
libpq.x86_64 16.1-4.fc40 @fedora
This is the older version provided by Fedora (Nov 2023!, even after 16.3 from May 2024)
3. Questions
- Why doesn't psql use the just created lib64/libpq.so.5.17 from ninja install?
The loading of the locally available libpq.so should always have priority over a system wide in /usr/lib64
- Why is the Fedora supplied library 2 minor versions behind?
- How to install the new libpq systemwide to make it usable for all applications (not only postgres supplied clients)?
To my understanding libpq is normally downward compatible, so it may be possible to use libpq17 against all supported older releases
4. Proposals
- The distributors like Fedora, Debian,Ubuntu etc. should be encouraged to update the minor versions IN A TIMELY FASHION like any other upgrades: Minor versions normally don't break anything and often contain security fixes and important bug fixes valuable to all update-willing users of the system. Perhaps somebody deeper involved can support the distributors in this case.
- PGDG should provide the newest libpq.so (beta or stable) in its common repository starting at the first beta release of a major version.
So everybody can install it separately and test it against its own application. This should ease real world testing alot.
- Due to the downward compatibility of libpq and the difficulty of handling multiple versions on the same machine I propose to always provide the newest libpq (highest stable version and latest beta version) for separate installation.
This should be independend installable from the main packages, much like the Visual runtime libraries for applications under Windows.
The user can choose between the latest stable version (at this time libpq 16.3), the latest beta (at this time libpq 17beta) or the version belonging to its major/minor version. This should be documented and be easyly changeable.
The buildfarm could be run always with the most current version. libpq could be thought of a separate product as base for all client applications.
5. Solving the problem
I don't know how to solve the problem in an official way.
I haven't tried manual changes in the system (copying binaries, changing symbolic links, making own packages etc.)
I am able to access the test database from outside (from a windows psql client of pg17b1), but this is not very practical.
The same problem occurs on my other machine running Fedora 39 and should occur in many other distributions also.
I think a self compiled version of postgres should be self-confined and ready to run for testing.
Any thoughts?
Hans Buschmann
pgsql-hackers by date: