E.4. Postgres Pro Standard 16.0.1 #
Release Date: 2023-10-19
E.4.1. Overview #
This release is based on PostgreSQL 16 and includes all the new features introduced in PostgreSQL 16. For their detailed description, see PostgreSQL 16 Release Notes. Other major changes and enhancements are as follows:
Added system views
pg_stats_vacuum_tables,pg_stats_vacuum_indexesandpg_stats_vacuum_database, which show statistics about vacuuming tables, indexes and databases, respectively. These statistics were previously available through pgpro_stats.Added new configuration parameters pgpro_build, pgpro_edition, and pgpro_version, which report the Postgres Pro source code commit ID, edition, and server version respectively.
Added predefined roles:
pg_create_tablespace, which allows executing theCREATE TABLESPACEcommand without superuser rights.pg_manage_profiles, which allows executing theCREATE PROFILE,ALTER PROFILE, andDROP PROFILEcommands without superuser rights.
Upgraded aqo to version 2.0, which provides the following major changes and enhancements:
The configuration is streamlined. Now aqo behavior mainly depends on three configuration parameters:
aqo.enable,aqo.modeandaqo.advanced, which respectively define aqo state, operation mode and whether statistics is isolated per query.The default values of configuration parameters set the recommended basic mode, where statistics is collected for plan nodes, and the collected machine learning data is used to correct the cardinality estimation error for all queries whose plan might contain a certain plan node.
aqo can now work with multiple databases independently.
Executing the
DROP/CREATE EXTENSIONcommand is now sufficient to instantly disable/enable aqo at the database level.Memory consumption is reduced.
Upgraded oracle_fdw to version 2.6.0.
Upgraded orafce to version 4.6.1.
Upgraded pg_integrity_check, which now provides three new options.
Upgraded pg_proaudit to version 1.2, which provides the following changes:
Changed the name of the
CONNECTevents recorded bypg_proaudittoAUTHENTICATE.Removed the
pg_proaudit.syslog_facilityandpg_proaudit.syslog_identconfiguration parameters. Instead, the syslog_ident and syslog_facility parameters can be used.Records in the syslog are now marked with
AUDITfor clear identification.Added the
db_nameargument for functions that add and delete the logging settings. This argument allows specifying the name of the database for which security events need to be logged. Also, therole_oidargument can now be passed withNULLto enable logging actions for all users.
Upgraded pg_probackup to version 2.6.6, which in particular improved stability of the
catchupcommand.Upgraded pgpro_pwr to version 4.3, which introduced a role model and added a few report tables.
Upgraded tds_fdw to version 2.0.3.
For the list of extension modules and utilities specific to Postgres Pro Standard, as well as the main user-visible core changes as compared to vanilla PostgreSQL, see Section 2.
E.4.2. Migration to Version 16 #
You can migrate to Postgres Pro Standard 16 from the same or a previous version of PostgreSQL (that is supported by the upgrade method chosen) and from a previous version of Postgres Pro Standard or Postgres Pro Standard Certified. The same holds for migration to Postgres Pro Standard Certified 16. See Section 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. Note that migration from Postgres Pro Standard to Postgres Pro Standard Certified of the same major version (or vice versa) is an update between Postgres Pro compatible versions (see Section 17.6 for more details).
To migrate from PostgreSQL or a Postgres Pro Standard release based on a previous PostgreSQL major version, make sure to install its latest available minor version and then perform a dump/restore using pg_dumpall or use the pg_upgrade utility.
If you choose to run pg_upgrade, make sure to initialize the new database cluster with compatible parameters. In particular, pay attention to the checksum settings in the cluster you are migrating from. If pg_upgrade creates any SQL files in its current directory, run these files to complete the upgrade.
When upgrading the installation from version 10 or lower, a dump/restore is recommended. In this case, you may have to resolve constraint violations manually. If this option is infeasible, you can still use pg_upgrade, but consult the Postgres Pro Standard support team since the integrity of indexes and constraints might be violated in some cases.
Note
To avoid conflicts, do not use the postgrespro-std-16 package to install the new Postgres 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, see Chapter 16.
For upgrade requirements imposed by vanilla PostgreSQL, see Section E.7.