Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1893324 - psql fails since libpq was bumped to 13.0 (undefined symbol: PQgssEncInUse)
Summary: psql fails since libpq was bumped to 13.0 (undefined symbol: PQgssEncInUse)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libpq
Version: rawhide
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Patrik Novotný
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks: F34BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2020-10-30 17:49 UTC by Adam Williamson
Modified: 2020-11-30 06:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-30 06:19:07 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Adam Williamson 2020-10-30 17:49:01 UTC 
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.
Comment 1 Adam Williamson 2020-10-30 17:50:03 UTC 
Note the libpq version bump did not come with an soname bump for libpq, it is still libpq.so.5.
Comment 2 Pavel Raiskup 2020-10-30 17:51:35 UTC 
Since there's the RHPG_10 string, I guess there's something wrong with the symbol versioning
we are downstream patching in.
Comment 3 Pavel Raiskup 2020-10-30 17:52:35 UTC 
Note this seems like a very good example of bug that would be catched by a trivial CI task.
Comment 4 Pavel Raiskup 2020-10-30 18:30:29 UTC 
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.
Comment 5 Honza Horak 2020-10-30 19:47:36 UTC 
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.
Comment 6 Honza Horak 2020-10-30 20:20:29 UTC 
(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.
Comment 7 Honza Horak 2020-10-30 20:29:36 UTC 
(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.
Comment 8 Adam Williamson 2020-11-30 06:19:07 UTC 
OK, this does look to be resolved at least insofar as the database server / client tests are passing on recent composes.
Note You need to log in before you can comment on or make changes to this bug.