1. 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
^^^^^^^^^^^^^^^^^^^^^^
So it was not possible to use the database locally with psql.
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
