E.13. Postgres Pro Enterprise 9.6.12.1
Release date: 2019-03-20
E.13.1. Overview
This release is based on PostgreSQL 9.6.12 and Postgres Pro Enterprise 9.6.11.1. All improvements inherited from PostgreSQL 9.6.12 are listed in PostgreSQL 9.6.12 Release Notes. As compared with Postgres Pro Enterprise 9.6.11.1, this version also provides the following changes:
Changed the default authentication method for installations on SUSE Linux Enterprise Server systems, as well as Red Hat Enterprise Linux 7 and its derivatives. Now local connections use the
peermethod, while network connections usemd5. For details on supported authentication methods, see Section 20.3.Backported the patch that addresses
dsm_attach()race condition when DSM handles are reused; in vanilla PostgreSQL, this fix is targeted for the future updates only. The patch is hoped to resolve issues when the server reports the following error message:ERROR: dsa_area could not attach to segment.Changed delivery model for pg_probackup utility:
On Linux, pg_probackup is now provided in the
pg-probackup-ent-9.6package. On ALT Linux and Debian-based systems, when upgrading from Postgres Pro Enterprise 9.6.11.1 or lower, runapt dist-upgrade(orapt-get dist-upgrade) to ensure that all new dependencies are handled correctly.On Windows, pg_probackup now has a separate installer. You have to install core components of the current Postgres Pro version before installing pg_probackup.
Started delivering pg_hint_plan separately:
On Linux, pg_hint_plan is now provided in the
pg-hint-plan-ent-9.6package.On Windows, pg_hint_plan now has a separate installer that should be run after the core components of the current Postgres Pro version are installed.
Added new options to Postgres Pro interactive installer for Windows. Now you can:
Choose
icuorlibcas the default collation provider. Previously, Postgres Pro Enterprise always usedicuby default.Select a Windows user that starts Postgres Pro service. By default, Postgres Pro service is started on behalf of
NT AUTHORITY\NetworkService.
Provided multiple improvements for autonomous transactions:
Added support for sharing PL/pgSQL variables between parent and autonomous transaction blocks.
Improved SQL syntax consistency: the
AUTONOMOUSkeyword can now be used withSTART,COMMIT/END, andROLLBACK/ABORTtransaction statements. Previously, onlyBEGINallowed this keyword.Fixed miscellaneous bugs to improve stability of autonomous transactions.
Implemented periodic client-server connection checks to detect broken connections earlier and free server resources upon disconnection. By default, the checks are performed every second. You can change this interval using the client_connection_check_interval configuration parameter.
Fixed amcheck to eliminate false-positive reports of invalid index structure, which were manifested by the following error message:
ERROR: heap tuple lacks matching index tuple within index.Fixed performance degradation for index-only scans over wide indexes.
Ended support for ALT Linux SPT 6.0 and Windows 7 SP1.
Changes in
rumandbloomindexes are now tracked correctly by pg_probackup in thePTRACKmode.Updated
pg_pathmanmodule to version 1.5.5. As compared to version 1.5.2 provided in the previous Postgres Pro releases, the following enhancements were introduced:Fixed
pg_pathmanupgrade scripts to avoid issues caused by a different the number ofpg_configattributes inpg_pathman1.4 and 1.5 major versions.Improved
pg_pathmanstability:Trying to call
pg_pathmanfunctions when this extension is disabled does not cause server failures anymore; now an error is raised instead.Different partitioning strategies can now be successfully applied to the same table.
Updated
pg_variablesmodule to version 1.2. As compared to the version provided in the previous Postgres Pro releases, the following enhancements were introduced:Added support for array types.
Improved module stability.
Changed empty package handling. An empty package is now removed only after the transaction that emptied it has ended.
(See Section F.49.)
E.13.2. Migration to Version 9.6.12.1
Depending on your current installation, the upgrade procedure will differ.
To migrate from vanilla PostgreSQL 9.6.x or Postgres Pro Standard, make sure you have installed its latest minor version and then perform a dump/restore using pg_dumpall.
To upgrade from a Postgres Pro Enterprise version based on the same PostgreSQL major release, a dump/restore is not required. It is usually enough to install the new version into the same installation directory. Once the new binaries are installed, the pgpro_upgrade script is run automatically to check whether additional setup is required and complete the upgrade.
Since pg_probackup delivery model changed in Postgres Pro Enterprise 9.6.12.1, when upgrading from a lower version on ALT Linux and Debian-based systems, run apt dist-upgrade (or apt-get dist-upgrade) to ensure that all new dependencies are handled correctly. On Windows, you have to run a separate pg_probackup installer to complete the upgrade.
When upgrading from versions 9.6.8.2 or lower, you have to rebuild indexes that used mchar or mvarchar types.
When upgrading from versions 9.6.2.1 or lower, you have to rebuild GiST indexes built over columns of the intarray type.
When upgrading from version 9.6.1.2 on RPM-based Linux distributions, make sure to move the data directory from pgsql to the pgproee directory before running the pgpro_upgrade script.
For some Linux distributions, you may be prompted to run pgpro_upgrade manually. In this case, you must stop the postgres service. The script must be run on behalf of the user owning the database (typically postgres) and PGDATA environment variable should be set to the directory where database resides. Running pgpro_upgrade as root will result in an error. This step is not required when upgrading from version 9.6.4.1 or higher.