Release date: 2018-02-02
This release is based on Postgres Pro Enterprise 9.6.6.3, and PostgreSQL 10.1. It 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. As compared with Postgres Pro Enterprise 9.6.6.3, this version adds the following new features:
pg_shardman. This experimental extension
enables sharding, aiming for scalability and fault tolerance
with transaction support. It provides best results for
OLTP workloads.
in-memory. This extension
enables you to store data in Postgres Pro Enterprise
shared memory. (See Section F.24.)
vops. This extension enables vertical data model
for Postgres Pro Enterprise. It can speed up OLAP queries
with filtering and aggregation by times. (See vops.)
Declarative syntax for partitioning uses pg_pathman
as the default partitioning engine.
(See Section F.40.2.6.)
SCRAM-SHA-256 algorithm implementation for password encryption is replaced with the one introduced in vanilla PostgreSQL. (See Section 20.3.2.)
Failover algorithm for libpq connections is replaced with vanilla PostgreSQL implementation.
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.
Postgres Pro Enterprise is now installed
to the /opt/pgpro/ent-10 directory,
while the default database is created in the
/var/lib/pgpro/ent-10/data directory.
You can now fully control the default database creation on all Linux distributions.
If you install the postgrespro-ent-10
package, it deploys all the Postgres Pro Enterprise
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 Enterprise 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 Enterprise 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 Enterprise,
as explained in Section 17.1.3. Do not install
the postgrespro-ent-10 package on the
same system with other PostgreSQL-based products
to avoid conflicts.
Note that postgrespro-common
and postgrespro-client-common
packages are no longer available on Debian-based systems.
For details, see Section 17.1.
The following features have been ported from Postgres Pro Enterprise 9.6.6.3:
aqo extension for adaptive query optimization.
(See Section F.3.)
multimaster and referee extensions.
(See Section F.32 and Section F.55, respectively.)
Extension pg_hint_plan has been added (See Section F.39)
pgpro_scheduler (See pgpro_scheduler.)
pg_tsparser text search parser. (See Section F.49.)
pg_wait_sampling extension for sampling-based statistics of wait events.
(See Section F.52.)
RUM index, based on GIN. (See Section F.56.)
Timeout for idle sessions on the server side. (See idle_session_timeout.)
Page-level compression (CFS). (See Chapter 32.)
Autonomous transactions support. (See Chapter 16.)
Support for relocatable tables (See pg_transfer)
Transaction IDs on 64-bit platforms use 64-bit data type
Consistent reads on standby servers. (See WAITLSN.)
pg_repack utility. (See pg_repack.)
K-nearest neighbor (k-NN) algorithm support for B-tree, GiST, and SP-GiST index types. (See Section 11.13.)
mamonsu monitoring service, which is implemented as a Zabbix agent. (See mamonsu.)
Handling transactions with serialization or deadlock errors in pgbench.
You can specify icu or libc as the provider
for the default collation when initializing a database cluster or creating a database. By default,
the icu provider is used for all locales except
C and POSIX.
For details, see Section 23.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 Standard 9.6 have been applied:
Covering indices patches
(For details, see the INCLUDE clause 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 libeditline
The following modules and utilities have been ported from Postgres Pro Standard 9.6:
hunspell-dict (See Hunspell Dictionaries Modules)
jsquery (See Section F.28)
pg_variables (See Section F.50)
pg_pathman (See pg_pathman)
pg_query_state (See Section F.43)
shared-ispell (See shared_ispell)
sr_plan (See sr_plan)
dump_stat (See dump_stat)
pg_buffercache (See pg_buffercache)
mchar (See Section F.31)
plantuner (See Section F.53)
fasttrun (See Section F.18)
fulleq (See Section F.20)
online_analyze (See Section F.33)
pg_pathman (See pg_pathman)
pg_probackup utility (See pg_probackup)
To migrate from PostgreSQL or Postgres Pro Standard, you should perform a dump/restore using pg_dumpall. pg_upgrade utility can only be used when upgrading from Postgres Pro Enterprise. Before migration, make sure to install the latest available minor version of your product.
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.
When migrating to Postgres Pro Enterprise 10, do not
use the postgrespro-ent-10
package to avoid conflicts. Use the individual packages instead.
In this case, server autostart needs to be enabled manually, if required.
Starting from Postgres Pro Enterprise 10, you can specify the provider for the default collation when initializing the database cluster or creating the database, as explained in Section 23.2.2. You must take it into account when upgrading to this release to avoid breaking indexes and constraints.
For PostgreSQL 9.5 and 9.5.1, as well as Postgres Pro 9.5.0.1 and 9.5.1.2, you cannot perform an upgrade to Postgres Pro Enterprise 10 directly. If you are using one of these versions, upgrade your installation to the latest available minor version first, such as Postgres Pro 9.5.20.1.
Similarly, if you are running Postgres Pro 9.6.10.x on Windows, you have to upgrade it to version 9.6.11.1 or higher.
When you are using pg_dumpall
to perform the upgrade, Postgres Pro Enterprise 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, unless you have databases with
non-C and non-POSIX collation settings. For such databases, you should
do the following:
If the new cluster is initialized with locales other than C or POSIX, and the database has an single-byte encoding, set LC_COLLATE to '@libc' for this database.
If the new cluster is initialized with C or POSIX locale settings and
the database has a multi-byte encoding, set LC_COLLATE to '@icu' for this database.
If the previous Postgres Pro Enterprise installation
contained any indexes or constraints depending on collations
other than the default collation of the database, C,
or 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
"Russian_Russia[.
or encoding]""English_United
States[..
In such cases, you can only use pg_upgrade to upgrade to
Postgres Pro Enterprise 10, as a dump/restore scenario may be impossible.
To resolve these issues, pg_upgrade declares such indexes and
constraints invalid and creates encoding]"reindex_text_indexes.sql
and validate_text_contraints.sql, respectively.
If you choose to run pg_upgrade when upgrading
from Postgres Pro Enterprise 9.6 versions,
make sure to initialize the new database cluster with the same
checksum setting
as the database cluster you are migrating from. To ensure that
that initdb sets the correct provider of the default collation
for the new database cluster, omit the provider option to select the required collation
provider automatically. In this case, libc provider
will be used for databases with C and POSIX locales, as well as for all
databases with single-byte encodings, while icu
provider 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.