From Fedora Project Wiki
Line 55: Line 55:


== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
The latest stable software is used by Fedora users, providing additional features and fixes.
 
      Be sure to include the following areas if relevant:
      If this is a major capability update, what has changed?
          For example: This change introduces Python 5 that runs without the Global Interpreter Lock and is fully multithreaded.
      If this is a new functionality, what capabilities does it bring?
          For example: This change allows package upgrades to be performed automatically and rolled-back at will.
      Does this improve some specific package or set of packages?
          For example: This change modifies a package to use a different language stack that reduces install size by removing dependencies.
      Does this improve specific Spins or Editions?
          For example: This change modifies the default install of Fedora Workstation to be more in line with the base install of Fedora Server.
      Does this make the distribution more efficient?
          For example: This change replaces thousands of individual %post scriptlets in packages with one script that runs at the end.
      Is this an improvement to maintainer processes?
          For example: Gating Fedora packages on automatic QA tests will make rawhide more stable and allow changes to be implemented more smoothly.
      Is this an improvement targeted as specific contributors?
          For example: Ensuring that a minimal set of tools required for contribution to Fedora are installed by default eases the onboarding of new contributors.
 
    When a Change has multiple benefits, it's better to list them all.
 
    Consider these Change pages from previous editions as inspiration:
    https://fedoraproject.org/wiki/Changes/Annobin (low-level and technical, invisible to users)
    https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo (low-level, but visible to advanced users)
    https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration (primarily a UX change)
    https://fedoraproject.org/wiki/Changes/NoMoreAlpha (an improvement to distro processes)
    https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->
The latest stable software is used by Fedora users.


== Scope ==
== Scope ==

Revision as of 14:48, 13 September 2022

PostgreSQL 15

Important.png
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.

Summary

Update of PostgreSQL (postgresql and libpq components) in Fedora from version 13 to version 14 in the non-modular (main) builds.

PostgreSQL 15.0 Release Notes

Owner

Current status

  • Targeted release: [[Releases/<number> | Fedora Linux <number> ]]
  • Last updated: 2022-09-13
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Update of PostgreSQL (postgresql and libpq components) in Fedora from version 14 to version 15 in the non-modular (main) builds.

This also involves moving the postgresql-static subpackage to libpq creating the libpq-static subpackage.

Feedback

Benefit to Fedora

The latest stable software is used by Fedora users, providing additional features and fixes.

Scope

  • Proposal owners:
    • Prepare PostgreSQL 15
    • Prepare PostgreSQL 14 as a module for Rawhide
    • Check software that requires or depends on postgresql-server or libpq packages for incompatibilities
    • Build PostgreSQL 15 (postgresql and libpq) to Rawhide
    • Rebuild depended on packages against PostgreSQL 15
    • Gather user input on the changes between PostgreSQL 14 and PostgreSQL 15
  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

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

Server plugins might require a newer version update because they sometimes have explicit server requirements. PostgreSQL maintainer will help fix/rebuild any issues in the plugins.

How to upgrade your database data from one PostgreSQL release to a newer one is described in Upgrading a PostgreSQL Cluster

How To Test

Usual testing as when upgrading between major PostgreSQL versions, running postgresql-setup --upgrade is necessary between major versions.

Test that all other software runs well with PostgreSQL 15.

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 15 server packages.

If users want to stick with PostgreSQL 14 for a little longer, there will be PostgreSQL 14 module

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 case of Postgresql-server, rebuild should be done to make sure all potential binary incompatibilities are handled.


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


Documentation

N/A (not a System Wide Change)

Release Notes