Дата выпуска: 2018-02-02
Этот выпуск основан на Postgres Pro 10.1.1 и Postgres Pro Enterprise 9.6.6.3. По сравнению с Postgres Pro Enterprise 9.6.6.3 эта версия приносит следующие нововведения:
pg_shardman. Это экспериментальное расширение реализует механизм горизонтального сегментирования (шардинг), позволяющий обеспечить масштабируемость и отказоустойчивость с поддержкой транзакций. Наилучшие результаты этот механизм обеспечивает с нагрузкой OLTP. (См. pg_shardman.)
in-memory. Это расширение позволяет размещать данные в разделяемой памяти Postgres Pro Enterprise. (См. Раздел F.24.)
vops. Данное расширение реализует вертикальную модель данных в Postgres Pro Enterprise. Этот подход позволяет многократно ускорить запросы OLAP с фильтрацией и агрегированием. (См. Раздел F.70.)
Декларативный синтаксис секционирования теперь по умолчанию использует pg_pathman в качестве механизма секционирования. (См. Подраздел F.40.2.7.)
Реализация метода шифрования паролей 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.56.)
Добавлено расширение pg_hint_plan (см. Раздел F.39)
pgpro_scheduler (См. pgpro_scheduler.)
Анализатор текстового поиска pg_tsparser. (См. Раздел F.50.)
Расширение pg_wait_sampling для периодического сбора статистики по событиям ожидания. (См. Раздел F.53.)
Индексы RUM, основанные на GIN. (См. Раздел F.57.)
Таймаут для простаивающих сеансов на стороне сервера. (См. 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.
Вся функциональность и усовершенствования, унаследованные от Postgres Pro 10.1.1, описаны в Замечаниях к выпуску Postgres Pro 10.1.1.
Для миграции на Postgres Pro Enterprise 10 рекомендуется выполнить выгрузку/восстановление данных, используя pg_dumpall. Утилиту pg_upgrade можно использовать только для перехода с Postgres Pro Enterprise версии 9.6.
При миграции на Postgres Pro Enterprise 10 во избежание конфликтов используйте не пакет postgrespro-ent-10, а отдельные пакеты. В этом случае автозапуск сервера нужно будет настроить вручную, если это потребуется.
Начиная с Postgres Pro Enterprise версии 10, при инициализации кластера баз данных или при создании базы может быть задан провайдер правил сортировки по умолчанию, как описано в Подразделе 23.2.2. Вы должны учитывать это при обновлении до данной версии, чтобы избежать повреждения индексов или ограничений.
Если в вашей текущей инсталляции Postgres Pro Enterprise используется ICU, не обновляйте версию библиотеки ICU. В противном случае обновление до Postgres Pro Enterprise 10 будет невозможно.
Версии 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 в базах с многобайтовыми кодировками имелись индексы или ограничения, зависящие от правил сортировки, отличных от C, POSIX или правила сортировки БД по умолчанию, в этих базах могли оказаться данные, нарушающие целостность индексов и условия ограничений. В Windows это также могло наблюдаться, если база данных с многобайтовой кодировкой содержала индексы или ограничения, зависящие от правила сортировки по умолчанию, имеющего длинное имя, например "Russian_Russia[. или кодировка]""English_United States[.. В таких случаях при обновлении Postgres Pro до версии 10 сценарий с выгрузкой/восстановлением данных может оказаться невозможным, и для обновления нужно будет использовать только pg_upgrade. Для устранения описанных проблем pg_upgrade объявляет такие индексы и ограничения нерабочими и создаёт скрипты кодировка]"reindex_text_indexes.sql и validate_text_contraints.sql, соответственно.
Если вы решите использовать pg_upgrade для обновления с Postgres Pro Enterprise версии 9.6, вы должны убедиться в том, что новый кластер баз данных имеет ту же характеристику контрольных сумм, что и кластер, из которого вы переносите данные. Чтобы программа initdb установила правильный провайдер правил сортировки по умолчанию в новом кластере, опустите указание провайдера, чтобы он был выбран автоматически. В этом случае провайдер libc будет выбран для баз данных с локалями C и POSIX, а также для баз с однобайтовыми кодировками, а во всех остальных случаях будет выбран провайдер icu. Если программа pg_upgrade создаст какие-либо файлы SQL в текущем каталоге, запустите их для завершения обновления.