Release Date: 2023-10-19
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_indexes and
pg_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
the CREATE
TABLESPACE command without superuser rights.
pg_manage_profiles,
which allows executing the CREATE
PROFILE, ALTER
PROFILE, and DROP
PROFILE commands 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.mode and aqo.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 EXTENSION command 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 CONNECT events recorded
by pg_proaudit to AUTHENTICATE.
Removed the pg_proaudit.syslog_facility and
pg_proaudit.syslog_ident configuration parameters.
Instead, the syslog_ident and
syslog_facility parameters can be used.
Records in the syslog are now marked with
AUDIT for clear identification.
Added the db_name argument 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, the
role_oid argument can now be passed with NULL
to enable logging actions for all users.
Upgraded pg_probackup
to version 2.6.6, which in particular improved stability of the
catchup command.
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.
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.
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.4.