As of now, we are building the libpq package separately from the postgresql package. Both packages build from the same source repository. By separating libpq from the postgresql package, it is possible for modular postgresql builds to share a single non-modular libpq package as a dependency. Until the upstream release 12.2, this approach was working beautifully. With this release, however, we've learned that we can't reliably build updated modular postgresql packages against the libpq package, without it being updated as well. For example, we couldn't build postgresql:10 updated to version 10.13 against libpq in version 12.1 (released at that time), despite version 12.1 being higher then 10.13. That is because the version 10.13 has been released two release cycles after the version 12.1. Actually, version 12.3 has been released in the same cycle as the version 10.13. As PostgreSQL upstream often backports features across their major versions, in this case, there were features introduced in 12.3, those features were backported to 10.13, but still missing in our release of libpq in version 12.1. Thus, to update the postgresql package to 10.13, the libpq package had to be updated to version 12.3. The above already means we're not benefiting from the split of libpq as much as anticipated. Though, more concerning was the upstream release of version 13.1. Since some features introduced[1] in libpq 13.1 weren't backported to any other major version supported by upstream, and caused a minor incompatibility for postgresql:12, postgresql:10 and postgresql:9.6, while postgresql:13 relies on them, we need to resolve this incompatibility downstream. That is not ideal. Especially as there could be more serious incompatibilities in future releases, and/or they could be hard to detect. Also, upstream has advised strongly against such packaging design[2]. To address this issue, while maintaining the separate libpq build, which is beneficial in certain use-cases, we will introduce a new packaging design: - each postgresql modular build will bundle corresponding version of the libpq library - this bundled libpq will be hidden by prefixing the library SONAME - the non-modular libpq package will be kept as is, and maintained independently from the postgresql packages This change will be included in a planned F34 change proposal, which I will reference here once completed. [1] https://www.postgresql.org/message-id/ce7881f6-bf37-7696-0f1f-e7f07eaaaaf5@2ndQuadrant.com [2] https://www.postgresql.org/message-id/2147994.1592920488%40sss.pgh.pa.us
Update to 1.5.0 for PostgreSQL 13 support https://src.fedoraproject.org/rpms/pgaudit/pull-request/4
Update postgresql to 13.1 and postgresql-setup to v8.5 https://src.fedoraproject.org/rpms/postgresql/pull-request/24
Update of postgres-decodebufs: https://src.fedoraproject.org/rpms/postgres-decoderbufs/pull-request/4
Update for rhdb-utils: https://src.fedoraproject.org/rpms/rhdb-utils/pull-request/1
Update for postgresql-pgpool-II: https://src.fedoraproject.org/rpms/postgresql-pgpool-II/pull-request/6
Update for pgsphere: https://src.fedoraproject.org/rpms/pgsphere/pull-request/2
Update for pg_repack: https://src.fedoraproject.org/rpms/pg_repack/pull-request/1
Update for orafce: https://src.fedoraproject.org/rpms/orafce/pull-request/2
Update for postgresql-ip4r: https://src.fedoraproject.org/rpms/postgresql-ip4r/pull-request/1
This is a PoC of a change to build the postgresql server with own copy of libpq (with mangled soname to not conflict with the libpq itself): https://src.fedoraproject.org/rpms/postgresql/pull-request/26
https://bodhi.fedoraproject.org/updates/FEDORA-2021-e20407327e
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
The current solution for building postgresql with a private libpq does not address the case when a server extension links to libpq as well. Currently, the postgresql-server-devel does not ship enough to allow such an extension to build without libpq installed, and with libpq installed we can get to situation when the system libpq and also the private libpq from the server are linked together in a single process. This needs some improvement.
(In reply to Honza Horak from comment #13) > The current solution for building postgresql with a private libpq does not > address the case when a server extension links to libpq as well. This PR should address this case as well: https://src.fedoraproject.org/rpms/postgresql/pull-request/32 In short, the private libpq is now available in a sub-package private-libs and private-devel, including the unversioned .so library and the header files, so extensions that need to link to libpq as well (like pg_repack), can do so with the private libpq.
(In reply to Honza Horak from comment #14) > (In reply to Honza Horak from comment #13) > > The current solution for building postgresql with a private libpq does not > > address the case when a server extension links to libpq as well. > > This PR should address this case as well: > https://src.fedoraproject.org/rpms/postgresql/pull-request/32 This change also adds an RPM requirement from postgresql-server-devel to either libpq-devel or private-devel, depending on whether server uses external libpq or not. With this, extensions like pg_repack do not need to have a dependency on libpq any more and can leave it up to postgresql-server-devel package to pull in some libpq (every-time).
@panovotn @fjanus I'd be happy if you can take a look at the PR in comment #14 and say what do you think about such approach.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days