E.26. Postgres Pro Standard 13.1.1
Release Date: 2020-12-17
E.26.1. Overview
This release is based onPostgreSQL 13.1 and includes all the new features introduced in PostgreSQL 13, as well as bug fixes implemented in PostgreSQL 13.1. For their detailed description, seePostgreSQL 13 Release Notes andPostgreSQL 13.1 Release Notes, respectively. Other major changes and enhancements are as follows:
Addedpgpro_pwr extension. It enables you to generate workload reports, which help to discover most resource-intensive activities in your database.
Addedpgpro_stats toPostgres Pro Standard. This extension combines tracking execution statistics of SQL statements and calculating wait event statistics.
Added support for OSnova 2.0. This is the first major release to support this OS family.
Upgradedmchar to version 2.2. SeeSection E.26.2 for related upgrade instructions.
For the list of extension modules and utilities specific toPostgres Pro Standard, as well as the main user-visible core changes as compared to vanillaPostgreSQL, seeSection 2.
E.26.2. Migration to Version 13
You can migrate toPostgres Pro Standard 13 from the same or a previous version ofPostgreSQL (that is supported by the upgrade method chosen) and from a previous version ofPostgres Pro Standard. SeeSection 17.6 for the methods to upgrade your database cluster. Consult the Postgres Pro Standard support team if you experience issues during migration. Backward migration is not supported.
To migrate fromPostgreSQL or aPostgres Pro Standard release based on a previousPostgreSQL major version, make sure to install its latest available minor version and then perform a dump/restore usingpg_dumpall or use thepg_upgrade utility:
If you choose to runpg_upgrade, make sure to initialize the new database cluster with compatible parameters. In particular, pay attention to the provider of the default collation and thechecksum settings in the cluster you are migrating from. Ifpg_upgrade creates any SQL files in its current directory, run these files to complete the upgrade.
If you are opting for a dump/restore, do not forget to use the
--add-collprovideroption to correctly choose the provider for the default collation of the migrated database.
To find out the default collation and its provider in the original cluster, see thedatcollate value for thetemplate0 database in thepg_database catalog. If you are upgrading from a version where provider of the default collation is not specified, uselibc provider if upgrading from vanillaPostgreSQL, and omit the provider if upgrading from earlier versions ofPostgres Pro.
Besides, note the following collation-related upgrade specifics described below.
On Windows,Postgres Pro Standard installations could contain databases with default collations provided by ICU, where the name of the database default collation used a syntactically correct BCP 47 language tag format, but had a wrong language code or other parameters, which invalidated the database default collation name for ICU.
If this issue affects thetemplate0 database, you will get the following error message when trying to initialize the cluster with the same collation:failed to get the canonical name for collation locale. In this case, you can only use dump/restore for upgrade, specifying a valid locale for the selected collation provider.
If this issue affects other databases, you will get the same error message whenPostgres Pro tries to create these databases with invalid collation in the new cluster. In this case, you can try the following:
Make a dump of the database usingpg_dump; it is required to use
--createand--format=plainoptions.Change the provider for the default collation of the database in the dump file from
'@icu'to'@libc'.Inpsql, restore the modified dump to complete the upgrade. This operation may fail if any constraints depending on the database collations are violated. In this case, you can try resolving the issues manually.
In some corner cases, using dump/restore could lead to invalid constraints in the restored databases, so you should usepg_upgrade. For example:
If the installation ofPostgres Pro Standard 9.6 or lower contained any indexes or constraints depending on collations other than the default collation of the database,
C, orPOSIXin databases with multibyte encodings, indexes and constraints in such databases could become inconsistent when these databases are migrated toPostgres Pro 10 or higher. On Windows, this situation can also happen if the database with a multibyte encoding contained any indexes or constraints depending on the default collation with a verbose name, such as"Russian_Russia[.orencoding]""English_United States[..encoding]"For upgrades fromPostgres Pro Standard 10, if the cluster has no information about the ICU library version, the ICU collation versions are checked to ensure that indexes and constraints remain valid after the upgrade. However, for clusters that contain databases with default ICU collations but have no information about the ICU library version and/or its collation versions, it is impossible to check that the current version ofPostgres Pro uses the same version of the ICU library.
On Windows, inPostgres Pro Standard 10 clusters with default collations provided by ICU, the ICU collation locale may not match the corresponding
libccollation locale.
If you usepg_upgrade, it declares such indexes and constraints invalid and createsreindex_text_indexes.sql andvalidate_text_constraints.sql, respectively. You have to run these files to complete the upgrade.
Note
To avoid conflicts on Linux systems, do not use thepostgrespro-std-13 package to install the newPostgres Pro binaries. Use the individual packages instead. In this case, server autostart needs to be enabled manually, if required. For details on the available packages, seeChapter 16.
If you usedmchar, to ensure acceleration of theLIKE operator after upgrading from previous versions ofPostgres Pro, run:
ALTER EXTENSION mchar UPDATE;
For upgrade requirements imposed by vanillaPostgreSQL, seeSection E.48.