F43 Change Proposal: PostgreSQL 18 (self contained)

Project Discussion Change Proposals
,
1

PostgreSQL 18

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announcd

:link: Summary

Update of default PostgreSQL stream (postgresql and libpq components) in Fedora from version 16 to version 18. This continues the versioned packaging structure introduced in Fedora 40.

:link: Owner

:link: Detailed Description

Following the Fedora 40+ PostgreSQL packaging model, each major version of PostgreSQL is delivered as a separate SRPM. The default PostgreSQL stream is selected by naming the packages as postgresql, postgresql-server, etc., while non-default versions use versioned names like postgresql17.

For Fedora 43, the PostgreSQL 18 SRPM will provide the default PostgreSQL implementation. The following mapping will apply: postgresql SRPM → deprecated postgresql16 SRPM → postgresql16, postgresql16-server, …
postgresql17 SRPM → postgresql17, postgresql17-server, …
postgresql18 SRPM → postgresql, postgresql-server, …

This also involves updating and rebuilding the PostgreSQL plugins that depend on postgresql server.

:link: Feedback

:link: Benefit to Fedora

The latest stable software is provided for Fedora users.

:link: Scope

  • Proposal owners:

    • Prepare PostgreSQL 18 as the default stream
    • Prepare PostgreSQL 16 as a non-default stream
    • Check software that requires or depends on postgresql-server or libpq packages for incompatibilities
    • Build PostgreSQL 18 (postgresql and libpq) for Rawhide
    • Build PostgreSQL 16 for Rawhide
    • Rebuild dependent packages against PostgreSQL 18

  • Other developers:

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Community Initiatives:

:link: Upgrade/compatibility impact

The PostgreSQL client library (libpq component) is compatible. So, there shouldn’t be any compatibility issues, but rebuild of the dependent components is recommended.

Server plugins might require a newer version update because they sometimes have explicit server requirements.

:link: How To Test

All PG server plugins should be installable. postgresql-setup --upgrade command should succeed.

Test that all other software runs well with PostgreSQL 18.

:link: User Experience

The users will have to upgrade their databases the same way as between major PostgreSQL versions, aka postgresql-setup --upgrade after installing PostgreSQL 18 server packages.

If users want to stick with PostgreSQL 16 for a little longer, there will be PostgreSQL 16 as nondefault PostgreSQL stream

:link: Dependencies

There are some packages (mostly server plugins), that build on top of PostgreSQL. Since the separation of PostgreSQL client library (libpq component), only packages that build server plugins should use postgresql package in BuildRequires. Others should use libpq. In the case of Postgresql-server, a rebuild should be done to ensure all potential binary incompatibilities are handled.

  • PostgreSQL server dependecies
    • perl-DBD-Pg
    • pgaudit
    • qt
    • qt3
    • qt5-qtbase
    • postgres-decoderbufs
    • gambas3
    • kdb
    • kea
    • libpqxx
    • openvas-manager
    • orafce
    • pg-semver
    • pgRouting
    • pgadmin3
    • pgsphere
    • postgis
    • postgresql-ip4r
    • postgresql-pgpool-II
    • qt3
    • rdkit
    • rhdb-utils
    • timescaledb
    • pg_repack

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

Revert the changes and provide PostgreSQL 16 only.

:link: Documentation

Upgrade strategy: PostgreSQL: Documentation: 18: 18.6. Upgrading a PostgreSQL Cluster

N/A (not a System Wide Change)

:link: Release Notes

Release notes for PostgreSQL 18 release: PostgreSQL: Documentation: 18: PostgreSQL 18beta1 Documentation

Overall overview of the changes and improvements: PostgreSQL: Documentation: 18: E.1. Release 18

Last edited by @amoloney 2025-07-10T11:28:43Z

Last edited by @amoloney 2025-07-10T11:28:43Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

In favor of latest stable postgresql being made available, however seeing as how postgresql 18 is still in beta, I would not want to see this propagated to the Fedora Server side. We should more likely follow a n -1 as the default for the distribution while still making the latest available. i.e. Fedora 43 should default to posgresql 17 not 18. Postgresql 17 will still have 3.5 years remaining on it’s supported lifespan, and postgresql 18 will at most be several months into its service life. I would suggest defaulting to 18 in Fedora 44 instead. I will roll with it either way, but databases and latest often have a some hidden surprises during the first six months following general release.

4

Postgresql 18 is planned to release in September and fedora 43 in October.

2 Likes
5

This change proposal has now been submitted to FESCo with ticket #3453 for voting.

To find out more, please visit our Changes Policy documentation.