Since libpq 13.0 landed in Rawhide, `psql` commands (and probably other stuff from the postgresql package) are failing with this error: psql: symbol lookup error: psql: undefined symbol: PQgssEncInUse, version RHPG_10 This breaks postgresql server deployment, which violates Basic criterion "It must be possible to configure a Fedora Server system installed according to the above criteria as a postgresql database server, using the official deployment tools provided in the distribution postgresql packages", so proposing as a Beta blocker.
Note the libpq version bump did not come with an soname bump for libpq, it is still libpq.so.5.
Since there's the RHPG_10 string, I guess there's something wrong with the symbol versioning we are downstream patching in.
Note this seems like a very good example of bug that would be catched by a trivial CI task.
The problem is actually caused by edeb3b955972d960f5f0eddf0f44891d77f22293, when we forgot to specify that several symbols were added in v12. Introducing them in v13 caused the troubles now.... this problem is now hard to fix correctly, I think we need to rebuild everything which depends on libpq now (ideally in all Fedora versions with libpq v12). If there are third party libpq consumers, they need to rebuild, too.
I'd actually like to fix this soon and deal with any wrong builds (if there are any during the last few days). A PR that should fix this unfortunate rebuild is prepared in https://src.fedoraproject.org/rpms/libpq/pull-request/4.
(In reply to Honza Horak from comment #5) > https://src.fedoraproject.org/rpms/libpq/pull-request/4. To be more concrete -- this ^^ PR reverts the changes in older symbols (those that were supposed to be marked PG_12), but I'm not sure now whether it is a good solution long-term.
(In reply to Honza Horak from comment #6) > To be more concrete -- this ^^ PR reverts the changes in older symbols > (those that were supposed to be marked PG_12), but I'm not sure now whether > it is a good solution long-term. I'd probably go with this (revert the breaking change) for now, and re-introduce the change again in a site-tag. That way we'd be able to fix the packages in Fedora at least. The 3rd party packages will still see a problem, but it is IMO acceptable when going from F33 to F34.
OK, this does look to be resolved at least insofar as the database server / client tests are passing on recent composes.