Postgres Pro Enterprise
10
RUENRU EN
E.34. Postgres Pro Enterprise 10.1.1
Пред. НаверхПриложение E. Замечания к выпускамНачало След.

E.34. Postgres Pro Enterprise 10.1.1

E.34.1. Обзор
E.34.2. Миграция на версию 10

Дата выпуска: 2018-02-02

E.34.1. Обзор

Этот выпуск основан на Postgres Pro Enterprise 9.6.6.3 и PostgreSQL 10.1. Он включает все новшества, реализованные в PostgreSQL 10, а также исправления ошибок, вошедшие в PostgreSQL 10.1. Подробное их описание можно найти в Замечаниях к выпуску PostgreSQL 10 и Замечаниях к выпуску PostgreSQL 10.1, соответственно. По сравнению с Postgres Pro Enterprise 9.6.6.3 эта версия также содержит следующие изменения:

  • pg_shardman. Это экспериментальное расширение реализует механизм горизонтального сегментирования (шардинг), позволяющий обеспечить масштабируемость и отказоустойчивость с поддержкой транзакций. Наилучшие результаты этот механизм обеспечивает с нагрузкой OLTP.

  • in-memory. Это расширение позволяет размещать данные в разделяемой памяти Postgres Pro Enterprise. (См. Раздел F.24.)

  • vops. Данное расширение реализует вертикальную модель данных в Postgres Pro Enterprise. Этот подход позволяет многократно ускорить запросы OLAP с фильтрацией и агрегированием. (См. vops.)

  • Декларативный синтаксис секционирования теперь по умолчанию использует pg_pathman в качестве механизма секционирования. (См. Подраздел F.40.2.6.)

  • Реализация метода шифрования паролей SCRAM-SHA-256 заменена реализацией, включённой в ванильный PostgreSQL. (См. Подраздел 20.3.2.)

  • Алгоритм переключения узлов для подключений libpq заменён реализацией, включённой в ванильный PostgreSQL.

  • Унифицирована структура пакетов двоичной установки для разных дистрибутивов Linux. Новая структура пакетов отличается от структуры ванильного PostgreSQL, но даёт следующие преимущества:

    • Вам не нужно беспокоиться о специфике инсталляций в разных дистрибутивах Linux при миграции между различными поддерживаемыми системами Linux. Postgres Pro Enterprise теперь устанавливается в каталог /opt/pgpro/ent-10, а база данных по умолчанию создаётся в каталоге /var/lib/pgpro/ent-10/data.

    • Теперь вы можете полностью управлять созданием базы данных по умолчанию во всех дистрибутивах Linux. Если вы устанавливаете пакет postgrespro-ent-10, он разворачивает все пакеты Postgres Pro Enterprise, необходимые для вашей системы, создаёт базу данных по умолчанию и настраивает сервер полностью автоматическим образом. Если вы устанавливаете отдельные пакеты, вам нужно настроить Postgres Pro Enterprise самостоятельно. В этом случае вы должны вручную инициализировать кластер баз данных и запустить сервер, а также настроить автозапуск сервера, если требуется.

    • Вы можете установить Postgres Pro Enterprise 10 рядом с другими продуктами на базе PostgreSQL для осуществления миграции или параллельного использования. Если вы выбираете отдельные пакеты, ваша системная конфигурация будет сохранена, так что вам придётся вручную настроить Postgres Pro Enterprise, следуя инструкциям в Подразделе 17.1.3. Не устанавливайте пакет postgrespro-ent-10 в системе, где уже установлен другой продукт на базе PostgreSQL, во избежание конфликтов.

    Заметьте, что пакеты postgrespro-common и postgrespro-client-common для систем на базе Debian теперь отсутствуют. За подробностями обратитесь к Разделу 17.1.

Из Postgres Pro Enterprise 9.6.6.3 была перенесена следующая функциональность:

  • Расширение aqo для адаптивной оптимизации запросов. (См. Раздел F.3.)

  • Расширения multimaster и referee. (См. Раздел F.32 и Раздел F.55.)

  • Добавлено расширение pg_hint_plan (см. Раздел F.39)

  • pgpro_scheduler (См. pgpro_scheduler.)

  • Анализатор текстового поиска pg_tsparser. (См. Раздел F.49.)

  • Расширение pg_wait_sampling для периодического сбора статистики по событиям ожидания. (См. Раздел F.52.)

  • Индексы RUM, основанные на GIN. (См. Раздел F.56.)

  • Тайм-аут для простаивающих сеансов на стороне сервера. (См. idle_session_timeout.)

  • Сжатие на уровне страниц (CFS). (См. Главу 32.)

  • Поддержка автономных транзакций. (См. Главу 16.)

  • Поддержка перемещаемых таблиц (См. pg_transfer)

  • Для идентификаторов транзакций на 64-битных платформах используется 64-битный тип данных

  • Согласованное чтение на ведомых серверах. (См. WAITLSN.)

  • Утилита pg_repack. (См. pg_repack.)

  • Поддержка алгоритма поиска k ближайших соседей (k-NN) для индексов типа B-дерева, GiST и SP-GiST. (См. Раздел 11.13.)

  • Служба мониторинга mamonsu, исполненная в виде агента Zabbix (см. mamonsu)

  • Повторение транзакций с ошибками сериализации и взаимоблокировки в pgbench.

  • Возможность установки icu или libc в качестве провайдера основного правила сортировки при инициализации кластера баз данных или создании базы данных. По умолчанию для всех локалей, кроме C и POSIX, используется провайдер icu. За подробностями обратитесь к Подразделу 23.2.2.

  • В индексе-B-дереве дублирующиеся ключи теперь хранятся в единственном экземпляре, вместо дубликатов хранятся указатели на элементы в списке. Это может значительно сократить размер индекса, когда один ключ встречается многократно.

Ключевые доработки, перенесённые из Postgres Pro Standard 9.6:

  • Доработки покрывающих индексов (За подробностями обратитесь к описанию предложения INCLUDE в CREATE INDEX.)

  • Исправления для системы сборки win32

  • Добавлена SQL-функция pgpro_version и соответствующие определения в pg_config.h

  • Внедрение механизма PTRACK

  • В psql для Windows включена поддержка редактирования командной строки с использованием libeditline

Из Postgres Pro Standard 9.6 перенесены следующие модули и утилиты:

E.34.2. Миграция на версию 10

Для перехода с PostgreSQL или Postgres Pro Standard требуется выполнить выгрузку/восстановление данных, используя pg_dumpall. Утилиту pg_upgrade можно использовать только для перехода с Postgres Pro Enterprise. Прежде чем производить переход, обязательно установите последний корректирующий выпуск для вашего продукта.

При переходе с PostgreSQL или Postgres Pro Standard обязательно уделите внимание особенностям реализации, связанным с 64-битными идентификаторами транзакций. Если вы ранее использовали явные приведения идентификаторов транзакций к 32-битным целым, вы должны заменить их на приведения к типу bigint, так как 64-битные идентификаторы транзакций имеют такой тип.

При миграции на Postgres Pro Enterprise 10 во избежание конфликтов используйте не пакет postgrespro-ent-10, а отдельные пакеты. В этом случае автозапуск сервера нужно будет настроить вручную, если это потребуется.

Начиная с Postgres Pro Enterprise версии 10, при инициализации кластера баз данных или при создании базы может быть задан провайдер основного правила сортировки как описано в Подразделе 23.2.2. Вы должны учитывать это при обновлении до данной версии, чтобы избежать повреждения индексов или ограничений.

Важно

Версии PostgreSQL 9.5 и 9.5.1, а также Postgres Pro 9.5.0.1 и 9.5.1.2 нельзя обновить непосредственно до Postgres Pro Enterprise 10. Если вы используете такую версию, сначала обновите вашу инсталляцию до самого последнего корректирующего выпуска, например, до Postgres Pro 9.5.2.1.

Также, если вы используете сервер Postgres Pro версии 9.6.10.x в Windows, сначала обновите его до версии 9.6.11.1 или выше.

Когда обновление осуществляется с применением pg_dumpall, Postgres Pro Enterprise использует провайдер правил сортировки, заданный в команде initdb для нового кластера. В этом случае индексы перестраиваются автоматически. Во избежание проблем с ограничениями, зависящими от правил сортировки, рекомендуется использовать провайдер libc при обновлении с ванильного PostgreSQL и опустить указание провайдера при обновлении с предыдущей версии Postgres Pro, если только в ваших базах не используются правила сортировки, отличные от C и POSIX. Для таких баз данных выполните следующее:

  • Если новый кластер инициализируется с локалью, отличной от C и POSIX, и при этом в базе используется однобайтовая кодировка, установите для этой базы в LC_COLLATE значение '@libc'.

  • Если новый кластер инициализируется с локалью C или POSIX, а в базе используется многобайтовая кодировка, установите для этой базы в LC_COLLATE значение '@icu'.

Примечание

Если в предыдущей инсталляции Postgres Pro Enterprise в базах с многобайтовыми кодировками имелись индексы или ограничения, зависящие от правил сортировки, отличных от C, POSIX или правила сортировки БД по умолчанию, в этих базах могли оказаться данные, нарушающие целостность индексов и условия ограничений. В Windows это также могло наблюдаться, если база данных с многобайтовой кодировкой содержала индексы или ограничения, зависящие от правила сортировки по умолчанию, имеющего длинное имя, например "Russian_Russia[.кодировка]" или "English_United States[.кодировка]". В таких случаях при обновлении Postgres Pro Enterprise до версии 10 сценарий с выгрузкой/восстановлением данных может оказаться невозможным и для обновления нужно будет использовать только pg_upgrade. Для устранения описанных проблем pg_upgrade объявляет такие индексы и ограничения нерабочими и создаёт скрипты reindex_text_indexes.sql и validate_text_contraints.sql, соответственно.

Если вы решите использовать pg_upgrade для обновления с Postgres Pro Enterprise версии 9.6, вы должны убедиться в том, что новый кластер баз данных имеет ту же характеристику контрольных сумм, что и кластер, из которого вы переносите данные. Чтобы программа initdb установила правильный провайдер основного правила сортировки в новом кластере, опустите указание провайдера, чтобы он был выбран автоматически. В этом случае для баз данных с локалями C и POSIX, а также для баз данных с однобайтовыми кодировками будет использоваться провайдер libc, а для всех остальных — провайдер icu. Если программа pg_upgrade создаст какие-либо файлы SQL в текущем каталоге, запустите их для завершения обновления.

Пред. Наверх След.
E.33. Postgres Pro Enterprise 10.2.1 Начало E.35. Выпуск 10.23
E.34. Postgres Pro Enterprise 10.1.1
Prev UpAppendix E. Release NotesHome Next

E.34. Postgres Pro Enterprise 10.1.1

E.34.1. Overview
E.34.2. Migration to Version 10

Release date: 2018-02-02

E.34.1. Overview

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:

E.34.2. Migration to Version 10

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.

Important

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.

Note

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[.encoding]" or "English_United States[.encoding]". 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 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.

Prev Up Next
E.33. Postgres Pro Enterprise 10.2.1 Home E.35. Release 10.23
FAQ