This release is based on PostgreSQL 10.1 and includes all the new features introduced in PostgreSQL 10, as well as bug fixes implemented in PostgreSQL 10.1. For their detailed description, see PostgreSQL 10 Release Notes and PostgreSQL 10.1 Release Notes, respectively. Other major changes and enhancements are as follows:
Unified the structure of binary installation packages across all Linux-based distributions. The new package structure differs from that of vanilla PostgreSQL, but offers the following benefits:
You do not need to worry about installation specifics on different Linux distributions when migrating between different supported Linux systems.
You can now fully control the default database creation on all Linux distributions. If you install the
postgrespro-std-10package, it deploys all the Postgres Pro packages required for your system, creates the default database, and configures the server in a fully automated way. If you install individual packages, you need to configure Postgres Pro yourself. In this case, you have to manually initialize the database cluster and start the server, as well as configure automatic server startup if required.
You can install Postgres Pro 10 side by side with other PostgreSQL-based products for seamless migration or parallel work. If you are using individual packages, your current system configuration will be preserved, so you have to manually configure Postgres Pro, as explained in Section 16.1.3. Do not install the
postgrespro-std-10package on the same system with other PostgreSQL-based products to avoid conflicts.
postgrespro-client-commonpackages are no longer available on Debian-based systems. For details, see Section 16.1.
You can specify
libcas the default collation provider when initializing a database cluster or creating a database. By default, the
icuprovider is used for all locales except
POSIX. For details, see Section 24.2.2.
In B-tree index, duplicate keys are now stored only once, with item pointers located in posting lists. It can significantly reduce the index size for workloads where the same key appears multiple times.
Core patches from Postgres Pro 9.6 have been applied:
Covering indices patches (For details, see the
INCLUDEclause description in CREATE INDEX.)
Fixes to win32 build system
Added pgpro_version SQL function and appropriate defines into pg_config.h
Integrated PTRACK patch
For Windows version of psql, enabled support for command-line editing using
The following modules and utilities have been ported from Postgres Pro 9.6:
hunspell-dict (See Hunspell Dictionaries Modules)
jsquery (See Section F.26)
pg_variables (See Section F.44)
pg_pathman (See Section F.36)
pg_query_state (See Section F.38)
shared-ispell (See shared_ispell)
sr_plan (See sr_plan)
dump_stat (See dump-stat)
pg_buffercache (See pg_buffercache)
mchar (See Section F.29)
plantuner (See Section F.46)
fasttrun (See Section F.17)
fulleq (See Section F.19)
online-analyze (See Section F.30)
pg_pathman (See Section F.36)
pg_probackup utility (See pg_probackup)
E.1.2. Migration to Version 10.1.1
To migrate to Postgres Pro 10, you can perform a dump/restore using pg_dumpall, or use the pg_upgrade utility. The first option is safer, while the second is faster and can significantly speed up the upgrade process for large databases. If you choose to run pg_upgrade, make sure to initialize the new database cluster with the same checksum setting as the database cluster you are migrating from.
When migrating to Postgres Pro 10, do not use the
postgrespro-std-10 package to avoid conflicts. Use the individual packages instead, as explained in Chapter 16.
Starting from Postgres Pro 10, you can specify the default collation provider when initializing the database cluster or creating the database, as explained in Section 24.2.2. You must take it into account when upgrading to this release to avoid breaking indexes and constraints.
If your current Postgres Pro installation uses ICU, do not update ICU library to a newer version. Otherwise, you cannot upgrade to Postgres Pro 10.
For PostgreSQL 9.5 and 9.5.1, as well as Postgres Pro 184.108.40.206 and 220.127.116.11, you cannot perform an upgrade to Postgres Pro 10 directly. If you are using one of these versions, upgrade your installation to an intermediate version first, such as Postgres Pro 18.104.22.168.
When migrating from vanilla PostgreSQL, specify
libcas the default collation provider.
When upgrading from Postgres Pro, omit the default collation provider option to select the required collation provider automatically. In this case,
libcprovider will be used for databases with C and POSIX locales, as well as for all databases with single-byte encodings, while
icuprovider will be used for all the other cases.
If pg_upgrade creates any SQL files in its current directory, run these files to complete the upgrade.
When you are using pg_dumpall to perform the upgrade, Postgres Pro uses the collation provider specified with the
initdb command for the new cluster. In this case, indexes are rebuilt automatically. To avoid issues with collation-dependent constraints, you are recommended to use
libc provider when upgrading from vanilla PostgreSQL, and omit the provider when upgrading from a previous version of Postgres Pro.
If the previous Postgres Pro installation contained any indexes or constraints depending on collations other than the default collation of the database,
POSIX in databases with multibyte encodings, such databases could contain some data that violated the specified constraints and made indexes inconsistent. 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
"English_United States[.. In such cases, you can only use pg_upgrade to upgrade to Postgres Pro 10, as a dump/restore scenario may be impossible. To resolve these issues, pg_upgrade declares such indexes and constraints invalid and creates
When building Postgres Pro manually, you must include ICU using the
--with-icu option. Otherwise, you cannot upgrade to Postgres Pro 10 from a previous Postgres Pro version.
For binary installations on Linux systems, the default directories have changed, as compared to Postgres Pro 9.6. Postgres Pro is now installed to the
/opt/pgpro/std-10 directory, while the default database is created in the
/var/lib/pgpro/std-10/data directory. Server autostart is disabled by default. Make sure to take this into account when upgrading to Postgres Pro 10. For details, see Section 16.1.