From Fedora Project Wiki
(Change submitted to FESCo https://pagure.io/fesco/issue/2337)
(More clear description of the contingency plan.)
Line 89: Line 89:


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: Fedora Modules available
* Contingency mechanism: If there are significant problems, we'll revert the change and users can opt in for postgres 12 from modules.
* Contingency deadline: beta freeze
* Contingency deadline: beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)

Revision as of 11:16, 6 February 2020

PostgreSQL 12

Summary

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

Owner

Current status

  • Targeted release: Fedora 32
  • Last updated: 2020-02-06
  • Tracker bug: TBD
  • Release Notes tracking: TBD
  • Release Engineering ticket: TBD

Detailed Description

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

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

Benefit to Fedora

Latest stable software is used by Fedora users.

Version v12 of PostgreSQL introduces several enhancements and performance improvements: https://www.postgresql.org/about/news/1976/ or https://www.postgresql.org/docs/12/release-12.html

Scope

  • Proposal owners:
    • Prepare PostgreSQL 12 as a module for Rawhide and at least one stable Fedora release (done)
    • Prepare PostgreSQL 11 as a module for Rawhide, so there would be a failover in case of problems
    • Build PostgreSQL 12 to Rawhide
    • Check software that requires or depends on postgresql-server or libpq packages for incompatibilities
    • Gather user input on the changes between PostgreSQL 11 and PostgreSQL 12
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: (a check of an impact with Release Engineering is needed)
  • 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 issues, but rebuild of the depended components is better to be sure. Most of the packages were already tested with the PostgreSQL 12 module. Server plugins might require a newer version update, because they sometimes have explicit server requirements. PostgreSQL maintainer will help fixing/rebuilding any issues in the plugins.

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 12.

User Experience

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

If users want to stick with PostgreSQL 11 for a little longer, there should be PostgreSQL 11 module. If users want to test it before it reaches Fedora 32, there is PostgreSQL 12 module already.

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 both the cases, rebuild should be done to make sure all potential binary incompatibilities are handled.

Contingency Plan

Modules will provide the functional version of PostgreSQL 11, available to all users.

  • Contingency mechanism: If there are significant problems, we'll revert the change and users can opt in for postgres 12 from modules.
  • Contingency deadline: beta freeze
  • Blocks release? N/A (not a System Wide Change)
  • Blocks product? N/A (not a System Wide Change)

Documentation

Upgrade startegy: https://www.postgresql.org/docs/12/upgrading.html

Release Notes

Release notes for PostgreSQL 12 release: https://www.postgresql.org/docs/12/index.html

Overall overview of the changes and improvements: https://www.postgresql.org/about/news/1976/ or or https://www.postgresql.org/docs/12/release-12.html