Movatterモバイル変換

• Added support for Ubuntu 18.10, Astra Linux Smolensk 1.6, and Red OS Murom 7 operating systems.

• Modified ICU usage specifics: ICU collation version is no longer stored in the cluster and therefore it is not checked when connecting to a database. For upgrade implications of this change, seeSection E.27.2.

• Updated planner/optimizer to improve planning speed and accuracy for several query types:

  • When estimating the sorting cost, the planner now takes into account comparison complexity, field width, and the number of comparison function calls required for each column, which results in fewer estimation errors.

  • For queries with several columns in theGROUP BY clause, it is now possible to choose the order of columns when sorting the data if it does not affect query accuracy. The more unique values the first sorted column contains, the less sorting is required for other columns. If all values in one of the columns are unique, it may be enough to sort data by that column only. The planner can also take advantage of the existing sorting results of index scans or theORDER BY clause.

  • If all tables to be joined have indexes, they are now used to estimate the number of rows in the joined result.

  • Self-joins are now eliminated from plans if it does not affect query results.

  • Planning for queries with multipleOR operators in theWHERE clause has been improved.

• Added support for Just-in-Time (JIT) compilation on Debian and Ubuntu systems, Astra Linux 1.6, ALT Linux 8, and CentOS 7. To use this functionality, you must install a separateJIT package and set up your environment as explained inChapter 16. To learn more aboutJIT, seeChapter 31.

• Updatedpg_probackup module to version 2.0.24. As compared to version 2.0.19 provided in the previousPostgres Pro releases, the following enhancements were introduced:

  • If unchanged since the previous backup, files that do not store relation data are now skipped in incremental backups.

  • Version number specified inpg_probackup.conf is now preserved when this file gets updated, which allows to correctly identifypg_probackup version used to take the backup.

  • Fixed an issue with restoring compressed file blocks and enhanced checks for compression errors. Previously,pg_probackup could not restore file blocks that thezlib algorithm failed to compress during backup. This issue could not be detected by the built-inpg_probackup validation mechanism as it occurs on a lower level that validation itself. You are recommended to re-validate existing backups using thispg_probackup version.

  • Improved validation algorithm. Files are now validated block by block by default, not only in case of file-level checksum mismatch. You can disable this behavior using the--skip-block-validation option.

  • Allowed restarting a backup merge if the previous attempt has been interrupted.

  • Allowed taking backups from standby servers without connecting to the master. Besides,pg_probackup now uses its built-in mechanism to determine the consistency point, so there is no risk that backups from standby contain any inconsistent data.

• Updatedpg_pathman module to version 1.5.2. As compared to version 1.4.14 provided in the previousPostgres Pro releases, the following enhancements were introduced:

  • Added support for multilevel partitioning.

  • Eliminated update triggers and addedpg_pathman.enable_partitionrouter parameter to enable/disable cross-partition updates.

  • Renamedget_pathman_lib_version() topathman_version().

  • Provided other miscellaneous bug fixes and improvements. For a full list of changes, seepg_pathman Wiki.

• Enabled NUL byte replacement with the specified ASCII code while loading data using theCOPY FROM command. Seenul_byte_replacement_on_import parameter description for details.

• Improvedplantuner stability and fixed a memory leak.

• Fixed an issue in index search that caused a slowdown when using complexjsquery values.

• Updatedpg-setup:

  • This script can now initialize the database cluster in a non-default location and store the correspondingPGDATA value in a system configuration file.

  • You can now runpg-setup with theset option to modify cluster configuration.

• Introduced the following changes for Windows version ofPostgres Pro:

  • PL/Perl now requires ActivePerl 5.26.

  • 32-bitPostgres Pro version is no longer provided.

• IntegratedICU patch. By default, theicu collation provider is used for all locales exceptC andPOSIX. For details, seeSection 22.2.2.

• Integrated PTRACK patch.

• For Windows version ofpsql, enabled support for command-line editing usingWinEditLine.

• Covering indexes have been committed toPostgreSQL 11, soPostgres Pro now inherits their modified implementation. If you have been using covering indexes before, you have to rebuild them after the upgrade.

• dump_stat (Seedump_stat)

• fasttrun (SeeSection F.15)

• fulleq (SeeSection F.17)

• hunspell-dict (SeeHunspell Dictionaries Modules)

• jsquery (SeeSection F.24)

• mchar (SeeSection F.27)

• online_analyze (SeeSection F.28)

• pg_pathman (Seepg_pathman)

• pg_query_state (SeeSection F.36)

• pg_probackup utility (Seepg_probackup)

• pg_tsparser (SeeSection F.41)

• pg_variables (SeeSection F.42)

• plantuner (SeeSection F.45)

• shared_ispell (Seeshared_ispell)

• sr_plan (Seesr_plan)

• If you choose to runpg_upgrade, make sure to initialize the new database cluster with compatible parameters. In particular, pay attention to the provider of the default collation and thechecksum settings in the cluster you are migrating from. Ifpg_upgrade creates any SQL files in its current directory, run these files to complete the upgrade.

• If you are opting for a dump/restore, do not forget to use the--add-collprovider option to correctly choose the provider for the default collation of the migrated database.

1. Make a dump of the database usingpg_dump; it is required to use--create and--format=plain options.

2. Change the provider for the default collation of the database in the dump file from'@icu' to'@libc'.

3. Inpsql, restore the modified dump to complete the upgrade. This operation may fail if any constraints depending on the database collations are violated. In this case, you can try resolving the issues manually or call the support team.

• If the installation ofPostgres Pro Standard 9.6 or lower contained any indexes or constraints depending on collations other than the default collation of the database,C, orPOSIX in databases with multibyte encodings, indexes and constraints in such databases could become inconsistent when these databases are migrated toPostgres Pro 10 or higher. 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[.encoding]" or"English_United States[.encoding]".

• For upgrades fromPostgres Pro Standard 10, if the cluster has no information about the ICU library version, the ICU collation versions are checked to ensure that indexes and constraints remain valid after the upgrade. However, for clusters that contain databases with default ICU collations but have no information about the ICU library version and/or its collation versions, it is impossible to check that the current version ofPostgres Pro uses the same version of the ICU library.

• On Windows, inPostgres Pro Standard 10 clusters with default collations provided by ICU, the ICU collation locale may not match the correspondinglibc collation locale.

Note

To avoid conflicts on Linux systems, do not use thepostgrespro-std-11 package to install the newPostgres 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, seeChapter 16.

Note

ForPostgreSQL 9.5 and 9.5.1, as well asPostgres Pro Standard 9.5.0.1 and 9.5.1.2, you cannot perform an upgrade toPostgres Pro Standard 11 directly. If you are using one of these versions, upgrade your installation to an intermediate version first, such asPostgres Pro Standard 9.5.2.1.

Similarly, if you are runningPostgres Pro Standard 9.6.10.x on Windows, you have to upgrade toPostgres Pro Standard 9.6.11.1 or higher.

Important

When upgrading from versions 10.3.2 or lower, you must call theREINDEX command for indexes that usedmchar ormvarchar types.