Request a Demo
E.1. Postgres Pro Enterprise 18.1.1
Prev UpAppendix E. Release NotesHome Next

E.1. Postgres Pro Enterprise 18.1.1 #

E.1.1. Overview
E.1.2. Migration to Version 18

Release Date: 2025-12-26

E.1.1. Overview #

This release is based on PostgreSQL 18.1 and includes all the new features introduced in PostgreSQL 18, as well as bug fixes implemented in PostgreSQL 18.1 update. For the detailed description, see PostgreSQL 18, and PostgreSQL 18.1 Release Notes.

For the list of extension modules and utilities specific to Postgres Pro Enterprise, as well as the main user-visible core changes over vanilla PostgreSQL, see Section 2. As compared to Postgres Pro Enterprise 17.7.1, the following differences are worth mentioning:

  • Added the ability to create tables that are divided into partitions by specifying a foreign key. The foreign key is used as a reference to the parent partitioned table and is defined by the PARTITION BY REFERENCE clause.

  • Added the pg_relation_logical_blocks function to compute the disk space used by relation forks for both compressed and uncompressed tables.

  • Added the new OLD_PASSWORD_TIME and OLD_PASSWORD_MAX parameters for the CREATE PROFILE and ALTER PROFILE commands. These parameters are required to enable authentication with the previous password. OLD_PASSWORD_TIME specifies for how long the previous password can be used for authentication alongside the new one. OLD_PASSWORD_MAX specifies the number of attempts to authenticate with the previous password before it is locked. The oid and passloginattempts fields were added to the pg_role_password catalog, and the pfloldpasswordtime and pfloldpasswordmax fields were added to the pg_profile catalog to display information related to previous passwords.

  • Added the new compute_plan_id configuration parameter that allows enabling and disabling in-core computation of query plan identifiers. Also added the plan_id field to the pg_stat_activity view to display plan identifiers.

  • Added the new extra_query_transformations configuration parameter that controls additional query tree transformations. This parameter replaces the enable_any_to_lateral_transformation and enable_extra_transformations parameters that were removed.

  • Added the append_optimized storage parameter that enables or disables bulk insertion into tables. This functionality allows reducing the time spent searching for buffers in shared memory and generating fewer WAL records.

  • Implemented the pg_temp_default tablespace for default storage of temporary objects, such as temporary tables, indexes on such tables, or temporary files that are created, for example, to store intermediate query results. This tablespace is created by default at cluster initialization. Besides, the spcpersistence column is added to the pg_tablespace catalog. Temporary tablespaces can store only temporary objects, while permanent tablespaces cannot store temporary objects. You can now also make a permanent tablespace temporary using the ALTER TABLESPACE command.

  • Implemented the following enhancements for the k-NN search:

    • Minimized the number of “primitive” index scans during index-only scans in cases when the ORDER expression argument is outside the bounds of ScalarArrayOp conditions.

    • Added the ability to merge several ScalarArrayOp conditions specified using the AND logical operator.

  • Allowed casting from the xid data type to the xid8 type.

  • Changed the Adaptive Query Execution behavior related to plan identifiers. Now for AQE operation, the compute_plan_id configuration parameter should be set to auto (default) or on to enable in-core computation of plan identifiers. Otherwise, AQE is disabled.

  • Improved the BiHA solution to provide the following features and optimizations:

    • Upgraded biha to version 1.7.

    • Implemented cascading replication for BiHA clusters. You can configure cascading replication when initializing a new BiHA cluster or GDBiHA cluster by means of the updated bihactl utility and then modify cascading replication configuration using max_replicas, preferred_roles, priority parameters and corresponding functions. If any replication source fails, BiHA re-configures cascading replication automatically.

    • Implemented experimental functionality that allows to unite nodes of the BiHA cluster into segments (logical nodes) that can be located in geographically distributed data centers. Data is transferred between segments via a single thread between the leader and the front follower — physical nodes located in the leader segment and the follower segment respectively. If the leader or front follower fails, data replication is re-configured automatically. If required, you can set the leader segment manually. For more information, refer to Geographical Distribution and Disaster Resilience.

    • Upgraded the bihactl utility that keeps former functionality and provides support for managing cascading replication and segments for geographical distribution and disaster resilience.

    • Added the biha.super_status_v view — the extended version of the biha.status_v view that additionally displays data for GDBiHA cluster.

    • Enhanced the logging functionality to provide better usability and log message clarity. Added separate logging levels for Postgres Controller and Config Controller components.

    • Implemented the service mode functionality managed by the biha.service_mode function. The service mode allows to temporarily pause BiHA operation. This may be required when you modify configuration parameters and want to ensure changes are applied on all cluster nodes.

    • Added the biha.monitoring function that allows monitoring the current status of BiHA cluster nodes. You can call this function from any node.

    • Added watchdog — a special protection mechanism that helps to prevent node hanging and split-brain issues. You can manage watchdog using the biha.watchdog_timeout configuration parameter.

  • Inherited the vanilla implementation of automatic removal of some unnecessary table self-joins. The corresponding enable_self_join_removal configuration parameter is removed; use enable_self_join_elimination instead.

  • Inherited the vanilla implementation of automatic transformations of x IN (VALUES (...), (...)) constructions into x = ANY([...]) constructions to get efficient query plans. The pgpro_planner extension is no longer required to perform these transformations.

  • Removed the deprecated pgpro_version, pgpro_edition, and pgpro_build functions. Use the pgpro_version, pgpro_edition, and pgpro_build configuration parameters instead.

  • Ended support for Debian 11.

  • Upgraded aqo to version 4.0 to implement optimizations that improve performance and significantly reduce overhead of query planning.

  • Upgraded pgpro_multiplan to change the logic to calculate plan identifiers for the planid field of the pgpro_multiplan_stats view. Now you should set the compute_plan_id configuration parameter to on to enable in-core computation of plan identifiers, which is used by pgpro_stats. Otherwise, the values of this field are set to 0.

  • Added the experimental KVik module to proxima. Designed for systems with high data-reading workloads, KVik provides in-memory caching of data stored in Postgres Pro databases and fast operation with cache via RESP (Redis Serialization Protocol). The main features of KVik are the following:

    • high-performance data reading

    • support of RESP commands, such as SET, GET, and DEL

    • automatic invalidation of cached data when modified via INSERT, UPDATE, and DELETE statements in Postgres Pro databases

    • automatic data update in Postgres Pro databases when modified in cache via SET and DEL operations

  • Upgraded the apache_age extension to version 1.6.1.

  • Upgraded orafce to version 4.16.3.

  • Upgraded pg_filedump to version 18.1.

  • Upgraded pg_hint_plan to version 1.8.0.1.

  • Upgraded pg_probackup to version 2.8.12 Enterprise.

  • Upgraded pgpro_controldata to version 18.2.0.

  • Upgraded pgpro-orautl to version 2.2.

  • Upgraded pgvector to version 0.8.1.

  • Upgraded tds_fdw to version 2.0.5.

  • Postgres Pro is no longer compatible with the citus extension.

  • Removed the deprecated vops extension.

E.1.2. Migration to Version 18 #

You can migrate to Postgres Pro Enterprise 18 from the same or a previous version of PostgreSQL (that is supported by the upgrade method chosen) or Postgres Pro Standard/Postgres Pro Standard Certified and from a previous version of Postgres Pro Enterprise/Postgres Pro Enterprise Certified. The same holds for migration to Postgres Pro Enterprise Certified 18. See Section 18.6 for the methods to upgrade your database cluster. Consult the Postgres Pro Enterprise support team if you experience issues during migration. Backward migration is not supported. Note that migration from Postgres Pro Enterprise to Postgres Pro Enterprise Certified of the same major version (or vice versa) is an update between Postgres Pro compatible versions (see Section 18.6 for more details).

To migrate from PostgreSQL, Postgres Pro Standard, or Postgres Pro Enterprise 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. You cannot use the pg_upgrade --swap option to upgrade to Postgres Pro Enterprise from PostgreSQL or Postgres Pro Standard due to incompatibility of heap and FSM page headers and from Postgres Pro Enterprise lower than version 14 due to incompatibility of the visibility map page format.

When migrating from PostgreSQL or Postgres Pro Standard, make sure to pay special attention to implementation specifics of 64-bit transaction IDs. If you have used explicit casts to 32-bit integers when handling transaction IDs, you have to replace them with casts to bigint since 64-bit transaction IDs are of the bigint type.

For the instructions on migrating your BiHA cluster to version 18, see migration instructions for BiHA.

Note

To avoid conflicts, do not use the postgrespro-ent-18 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 and installation instructions, see Chapter 17.

For other upgrade requirements imposed by vanilla PostgreSQL, see Section E.3.

Prev Up Next
Appendix E. Release Notes Home E.2. Release 18.1
epub pdf