Bug 1893324

Summary:	psql fails since libpq was bumped to 13.0 (undefined symbol: PQgssEncInUse)
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	libpq	Assignee:	Patrik Novotný <panovotn>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	rawhide	CC:	hhorak, panovotn, pkubat, praiskup, robatino
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	openqa
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-30 06:19:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1829022

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.