It’s been over 23 years since I started building PostgreSQL RPMs. It began as a hobby project so that I could install PostgreSQL on my Red Hat Linux 6.2 boxes and then on Fedora Core. It was not a proper repository back then. We set up the first yum.postgresql.org infrastructure (with a different domain name) around 2005 in Canada, followed by a proper source code repository and then finally integration into the PostgreSQL.org infrastructure: https://yum.postgresql.org
After I joined EDB in 2011, EDB let me spend full time on the community projects and the most notable one is the PGDG RPM repository. EDB also contributes to packaging QA efforts. Several EDB employees provide regular feedback about test results and we fix those issues immediately.
It is not just packaging software: We also follow the improvements in the RPM based world and apply changes whenever necessary. Also we test extensions before each release and also create issues for every piece of software if there is a compatibility issue with the upcoming PostgreSQL release.
The community PostgreSQL YUM repository does not just include PostgreSQL packages, but also some extensions that depend on a specific PostgreSQL version (e.g., PostGIS), packages in the PostgreSQL world that can be used against some (or all) PostgreSQL versions, and the supportive packages for those extensions (e.g., Proj, GEOS).
The repository has 4 main sets of packages:
- Non-common repository: PostgreSQL RPMs along with extensions or utilities which depend on a specific PostgreSQL release.
- Common repository: Packages that either support other packages in the non-common repository (like SFCGAL, GeOS) or packages that does not depend on a specific PostgreSQL version (Patroni, pg_activity, PoWA, pgPool, etc)
- Non-free repository: While the sources of them are open, they either depend on non-free software or have licenses that are not OSI-compliant.
- Extras repository: PGDG RPM repository includes a few non-PostgreSQL packages to support Patroni in HA environments or PostgreSQL packages that we normally don't distribute (written in go).
In total I maintain 346 different software packages and will add more!
The repository also supports many Linux distributions starting with their beta releases. This helps us release packages on the same day that upstream goes GA. We recently were able to support Red Hat Enterprise Linux 10 on its GA day, and we do the same for Fedora releases.
So this brings us to this week, when PostgreSQL 18 will be released! There are lots of exciting features coming with PostgreSQL 18, and they are already being mentioned here. In this post I will mention the new features and improvements in the community RPM packaging for v18.
OAuth2
One of the most significant features of PostgreSQL 18 is OAuth2 authentication. Below are EDB’s blog posts about this feature:
- Preview PostgreSQL 18’s OAuth2 Authentication (1) - Explore How it Works
- Preview PostgreSQL 18’s OAuth2 Authentication (2) - Building a Custom OAuth2 Validator by Rust
- Preview PostgreSQL 18's OAuth2 Authentication (3) - Enhancing a PostgreSQL Client Library to Speak OAUTHBEARER
OAuth2 support requires the RPMs to be compiled with curl support. Because of the nature of curl, this brings in some security concerns for most of the users (especially for the ones who will not use this feature). With joint coordination with the Debian packaging team we split OAuth2 shared library into a separate package called postgresql18-libs-oauth. The regular postgresql18-libs package works like the previous releases.
Io_uring
As a part of the AIO implementation, PostgreSQL 18 has support for making use of IO_uring on Linux servers for asynchronous I/O and can provide for some nice performance improvements. We embedded this feature into the RPMs. However RHEL 8 does not have this feature because the kernel on RHEL 8 is too old. io_uring feature has been released as a tech preview as of kernel-5.14.0-362.8.1.el9_3 in RHEL 9.3. So the best is using RHEL 10 (Kernel 6.12) to utilise this feature. SLES 15.7 runs kernel 6.4.0 which also has io_uring support as well.
NUMA awareness
PostgreSQL 18 also includes support for NUMA awareness. This feature is also fully embedded in all operating systems that RPMs are built on.
ECPG
PostgreSQL ECPG is an embedded SQL preprocessor for the C and C++ programming languages, allowing developers to write SQL statements directly within C/C++ code. This 24-year old feature has always been a part of the RPMs. We listened to our users and split ecpg libraries into its own subpackage called postgresql18-ecpg-libs. Users who will upgrade to PostgreSQL 18 will have to install this package separately. Also the development files for ECPG are shipped with postgresql18-ecpg-devel. These files used to be in the -devel subpackage in the previous releases.
More systemd integration
In this release I added integration with systemd-sysusers to cope with the changes that come with Fedora 43 release.
Personally, I find this release one of the most exciting in a long time!