E.27. Postgres Pro Standard 11.1.1

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

E.27.1. Обзор

Этот выпуск основан на PostgreSQL 11.1 и включает все новые возможности, появившиеся в PostgreSQL 11, а также исправления ошибок, вошедшие в PostgreSQL 11.1. Подробное их описание вы можете найти в Замечаниях к выпуску PostgreSQL 11 и в Замечаниях к выпуску PostgreSQL 11.1, соответственно. Ниже перечислены другие основные изменения и усовершенствования:

  • Добавлена поддержка операционных систем Ubuntu 18.10, Astra Linux «Смоленск» 1.6 и РЕД ОС 7 МУРОМ.

  • Изменён метод использования ICU: версия правила сортировки ICU теперь не хранится в кластере и, таким образом, не проверяется при подключении к базе данных. Как это отразилось на процедуре обновления, описано в Подразделе E.27.2.

  • Усовершенствован планировщик/оптимизатор, что позволило увеличить скорость и точность для нескольких типов запросов:

    • Оценивая стоимость сортировки, планировщик теперь принимает во внимание сложность сравнения, ширину полей и количество вызовов функции сравнения, требующееся для каждого столбца, что позволяет увеличить точность оценки.

    • Для запросов с несколькими столбцами в предложении GROUP BY при сортировке данных теперь может выбираться другой порядок столбцов, если это не влияет на точность запроса. Чем более уникальны значения в первом сортируемом столбце, тем проще будет сортировать остальные столбцы. Если в одном из столбцов уникальны все значения, может быть достаточно отсортировать данные только по этому столбцу. Планировщик может также воспользоваться существующими результатами сортировки, полученными при сканировании индекса или выполнении ORDER BY.

    • Если во всех соединяемых таблицах есть индексы, они будут использоваться для оценки числа строк в результате соединения.

    • Замкнутые соединения теперь исключаются из планов, если это не влияет на результаты запросов.

    • Улучшено планирование запросов со множеством операторов OR в предложении WHERE.

  • Добавлена поддержка JIT-компиляции (Just-in-Time, Компиляция «точно в нужное время») в системах Debian и Ubuntu, Astra Linux 1.6, Альт Линукс 8 и CentOS 7. Для использования этой функциональности вы должны установить отдельный пакет JIT и настроить окружение, как описывается в Главе 16. Подробнее JIT описывается в Главе 31.

  • Модуль pg_probackup обновлён до версии 2.0.24. Эта версия по сравнению с 2.0.19, поставляемой в предыдущем выпуске Postgres Pro, отличается следующими усовершенствованиями:

    • Файлы, которые не содержат данных и не изменились со времени предыдущего копирования, не включаются в инкрементальную копию.

    • Номер версии, заданный в pg_probackup.conf, теперь сохраняется при изменении этого файла, что позволяет точно узнать, какая версия pg_probackup применялась при создании резервной копии.

    • Устранена проблема восстановления сжатых блоков файлов и улучшены проверки ошибок сжатия. Ранее pg_probackup не мог восстановить блоки файлов, которые алгоритм zlib не смог сжать во время резервного копирования. Эту проблему нельзя было выявить встроенным механизмом проверки pg_probackup, так как она проявлялась на уровне ниже, чем уровень проверки. В сложившейся ситуации рекомендуется перепроверить существующие резервные копии, используя эту версию pg_probackup.

    • Улучшен механизм проверки целостности. Файлы теперь по умолчанию проверяются поблочно не только в случае несовпадения контрольной суммы на уровне файлов. Это поведение можно отключить с помощью параметра --skip-block-validation.

    • Появилась возможность перезапустить объединение резервных копий, если предыдущая попытка была прервана.

    • Реализована возможность снятия резервных копий с ведомых серверов без подключения к ведущему. Также в pg_probackup теперь появился встроенный механизм определения точки согласованности, исключающий риски несогласованности данных в копиях, сделанных на ведомых серверах.

  • Модуль pg_pathman обновлён до версии 1.5.2. Эта версия по сравнению с 1.4.14, входившей в предыдущий выпуск Postgres Pro, включает следующие усовершенствования:

    • Добавлена поддержка многоуровневого секционирования.

    • Ликвидированы триггеры на изменение и добавлен параметр pg_pathman.enable_partitionrouter, включающий межсекционные операции изменений.

    • Функция get_pathman_lib_version() переименована в pathman_version().

    • В новую версию вошли и другие улучшения и исправления ошибок. Полный список изменений можно найти на вики-странице pg_pathman.

  • Добавлена возможность замены нулевого байта заданным ASCII-символом при загрузке данных с помощью команды COPY FROM. Подробнее об этом можно узнать в описании параметра nul_byte_replacement_on_import.

  • Улучшена стабильность plantuner и устранена утечка памяти.

  • Устранена проблема в поиске по индексу, приводившая к замедлению при использовании сложных значений jsquery.

  • Усовершенствован скрипт pg-setup:

    • Теперь он может инициализировать кластер баз данных в нестандартном расположении и сохранить соответствующее значение PGDATA в системном конфигурационном файле.

    • Запустив pg-setup с ключом set, теперь можно изменить конфигурацию кластера.

  • Версию Postgres Pro для Windows затронули следующие изменения:

    • Для PL/Perl теперь требуется ActivePerl 5.26.

    • 32-битные версии Postgres Pro более не выпускаются.

Также были перенесены все усовершенствования, разработанные для Postgres Pro Standard 10, включая доработки ядра и модулей расширений.

Ниже перечислены основные видимые пользователям изменения, произошедшие в ядре, по сравнению с ванильным PostgreSQL:

  • Включено изменение в порядке использования ICU. По умолчанию провайдер правил сортировки icu задействуется для всех локалей, за исключением C и POSIX. Подробнее об этом рассказывается в Подразделе 22.2.2.

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

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

  • Реализация покрывающих индексов вошла в ванильную версию PostgreSQL 11, но с некоторыми изменениями, так что и в Postgres Pro они теперь реализуются по-другому. Если вы использовали покрывающие индексы ранее, вам потребуется перестроить их после обновления.

Из Postgres Pro Standard 10 были перенесены следующие модули расширений и утилиты:

E.27.2. Миграция на версию 11

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

  • Если вы решите использовать pg_upgrade, важно инициализировать новый кластер баз данных с совместимыми параметрами. В частности, обратите внимание на характеристику контрольных сумм и выбор провайдера основного правила сортировки в кластере, который вы будете обновлять. Если pg_upgrade создаст какие-либо скрипты SQL в текущем каталоге, выполните их для завершения обновления.

  • Если вы выбираете вариант с выгрузкой/восстановлением данных, не забудьте при выгрузке добавить ключ --add-collprovider, чтобы для обновляемой базы данных был установлен правильный провайдер основного правила сортировки.

Понять, какое правило сортировки является основным в старом кластере и какой провайдер оно использует, можно по значению datcollate для базы данных template0 в каталоге pg_database. Если вы производите обновление с версии, в которой провайдер основного правила сортировки не задан, опустите указание провайдера при переходе с предыдущих версий Postgres Pro или выберите провайдер libc при переходе с ванильного PostgreSQL.

Помимо этого, учтите описанные ниже особенности обновления, связанные с изменениями в использовании правил сортировки.

В Windows инсталляции Postgres Pro Standard могли содержать базы данных с основным правилом сортировки на базе ICU, имя которого имело синтаксически правильный формат языка BCP 47, но неправильный код языка или другие параметры, в результате чего это правило сортировки оказывалось недействительным для ICU.

Если эта проблема затрагивает вашу базу данных template0, при попытке инициализировать новый кластер с тем же правилом сортировки вы получите следующее сообщение об ошибке: failed to get the canonical name for collation locale (не удалось получить каноническое имя для локали правила сортировки). В этом случае выполнить обновление можно только путём выгрузки/восстановления данных, задав для нового кластера подходящую локаль для выбранного провайдера правил сортировки.

Если эта проблема затрагивает другие базы данных, вы получите то же сообщение об ошибке, что и при попытке создания в Postgres Pro нового кластера с некорректным правилом сортировки. Вы можете попытаться решить эту проблему следующим образом:

  1. Выгрузите базу данных, используя pg_dump; при этом необходимо указать параметры --create и --format=plain.

  2. Смените в выгруженном файле провайдер основного правила сортировки с '@icu' на '@libc'.

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

В некоторых особых случаях при выгрузке/восстановлении данных вы можете столкнуться с нарушением ограничений в восстанавливаемых базах данных, так что вместо этого метода лучше использовать pg_upgrade. В частности:

  • Если в инсталляции Postgres Pro Standard версии 9.6 или ниже содержались индексы или ограничения, зависящие от правил сортировки, отличных от основного правила сортировки БД, а также от C или POSIX в базах данных с многобайтными кодировками, индексы и ограничения в таких базах могли оказаться несогласованными при обновлении до Postgres Pro версии 10 или выше. В Windows эта ситуация также могла иметь место, если база данных с многобайтной кодировкой содержала индексы или ограничения, зависящие от основного правила сортировки с полным именем "Russian_Russia[.кодировка]" или "English_United States[.кодировка]".

  • При обновлении с Postgres Pro Standard версии 10 кластеров, в которых нет информации о версии библиотеки ICU, состояние актуальности индексов и ограничений определяется по версиям правил сортировки. Однако для кластеров, в которых содержатся базы данных с основным правилом сортировки на базе ICU, но отсутствует информация о версии библиотеки ICU и/или версиях правил сортировки, нет никакой возможности удостовериться в том, что в текущей версии Postgres Pro используется та же версия библиотеки ICU.

  • В Windows у кластеров Postgres Pro Standard 10 с основным правилом сортировки на базе ICU локаль правила сортировки может не совпадать с локалью соответствующего правила сортировки libc.

Когда вы используете программу pg_upgrade, она объявляет такие индексы и ограничения нерабочими и создаёт для их исправления файлы reindex_text_indexes.sql и validate_text_contraints.sql, соответственно. Для завершения обновления вам надо будет выполнить эти скрипты.

Примечание

Во избежание конфликтов в системах Linux не используйте пакет postgrespro-std-11 для установки исполняемых файлов Postgres Pro, а установите вместо него отдельные пакеты компонентов продукта. В этом случае режим автозапуска сервера, если он требуется, нужно будет включить вручную. Подробнее о предоставляемых пакетах вы можете узнать в Главе 16.

Примечание

Версии PostgreSQL 9.5 и 9.5.1, а также Postgres Pro Standard 9.5.0.1 и 9.5.1.2, обновить напрямую до версии Postgres Pro Standard 11 нельзя. Если вы используете одну из этих версий, сначала обновите инсталляцию до промежуточной версии, например, до Postgres Pro Standard 9.5.2.1.

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

Важно

При обновлении с версии 10.3.2 или ниже вы должны выполнить команду REINDEX для индексов, в которых используются типы mchar или mvarchar.

Другие особенности обновления, присущие и ванильной версии PostgreSQL, описаны в Разделе E.50.