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