Дата выпуска: 2020-03-20
Этот выпуск основан на PostgreSQL 12.2 и включает все новые возможности, появившиеся в PostgreSQL 12, а также исправления ошибок, вошедшие в корректирующие выпуски PostgreSQL 12.1 и 12.2. Подробное описание этих новшеств вы можете найти в замечаниях к выпускам PostgreSQL 12, PostgreSQL 12.1 и PostgreSQL 12.2, соответственно.
Список дополнительных модулей и утилит, добавленных в Postgres Pro Enterprise, а также перечень ключевых видимых пользователям изменений в ядре сервера по сравнению с ванильным PostgreSQL вы можете найти в Разделе 2. Ниже перечислены значимые отличия этой версии от Postgres Pro Enterprise 11.7.1:
Представление pg_recovery_settings стало ненужным, так как содержимое recovery.conf было включено в postgresql.conf и теперь его можно просмотреть через системное представление pg_settings; параметры primary_conninfo, restore_command и primary_slot_name можно изменять, не перезапуская сервер.
Модификация, сокращающая объём записей в WAL, генерируемых при создании индексов GiST, GIN и SP-GiST, вошла в PostgreSQL 12, поэтому продукты Postgres Pro теперь включают её в несколько изменённом виде. Формат индексов не поменялся, поэтому все индексы должны остаться в рабочем состоянии.
Механизм исключения дубликатов в индексах-B-деревьях претерпел важные изменения. Теперь вы можете отключить исключение дубликатов для создаваемых индексов, воспользовавшись параметром deduplicate_items команды CREATE INDEX. Кроме того, для некоторых классов операторов и типов данных исключение дубликатов в индексах-B-деревьях больше не поддерживается, о чём говорится в Подразделе 62.4.2. Влияние этих изменений на процедуру обновления освещается в Подразделе E.4.2.
Механизм PTRACK был основательно переработан и получил новый внешний API. Если ранее вы создавали резервные копии с использованием PTRACK в pg_probackup, вам нужно будет обновить pg_probackup до версии 2.2.6 или выше и настроить копирование PTRACK заново.
Встроенный пул соединений был существенно переработан и теперь не считается экспериментальным. Чтобы узнать больше о существующих особенностях использования этого механизма, обратитесь к Разделу 33.1.
Усовершенствовано расширение multimaster:
Расширение multimaster рекомендуется использовать в конфигурации с тремя узлами, один из которых является рефери. Подробнее о настройке кластера с рефери рассказывается в Подразделе F.30.3.3.
Теперь можно проверить согласованность данных на узлах кластера, используя функцию mtm.check_query().
В CFS улучшена функциональность управления сжатием:
Теперь вы можете выбирать алгоритмы сжатия. В выпускаемом Postgres Pro поддерживаются алгоритмы zstd (по умолчанию), zlib и pglz. Дополнительно могут быть добавлены и другие алгоритмы.
В представление pg_stat_activity добавлено поле wait_state_id для целей мониторинга.
Добавлен параметр plan_cache_lru_memsize, ограничивающий объём памяти, выделяемый для подготовленных операторов. По умолчанию это ограничение теперь равно 8 МБ, а параметр plan_cache_lru_size отключён.
Добавлено расширение pgpro_stats, которое не только собирает статистику выполнения SQL-операторов, но и подсчитывает статистику событий ожидания.
Расширение mchar обновлено до версии 2.1.
Расширение dump_stat обновлено до версии 1.2.
Начиная с Postgres Pro 12, использовать pg_pathman не рекомендуется. Применяйте вместо него реализованное в ванильной версии декларативное секционирование, описанное в Разделе 5.11.
Для перехода с PostgreSQL, Postgres Pro Standard или выпуска Postgres Pro Enterprise, основанного на предыдущей основной версии PostgreSQL, обязательно установите последний корректирующий выпуск вашего продукта. Выполните выгрузку/восстановление данных, используя pg_dumpall, или воспользуйтесь утилитой pg_upgrade. Помимо нижеперечисленных требований, примите во внимание все особенности обновления, присущие ванильному PostgreSQL, о которых рассказывается в Разделе E.9.
При переходе с PostgreSQL или Postgres Pro Standard обязательно уделите внимание особенностям реализации, связанным с 64-битными идентификаторами транзакций. Если вы ранее использовали явные приведения идентификаторов транзакций к 32-битным целым, вы должны заменить их на приведения к типу bigint, так как 64-битные идентификаторы транзакций имеют такой тип.
Во избежание конфликтов в системах Linux не используйте пакет postgrespro-ent-12 для установки исполняемых файлов Postgres Pro, а установите вместо него отдельные пакеты компонентов продукта. В этом случае режим автозапуска сервера, если он требуется, нужно будет включить вручную. Подробнее о предоставляемых пакетах и вариантах установки вы можете узнать в Главе 17.
Если вы решите использовать pg_upgrade, важно инициализировать новый кластер баз данных с совместимыми параметрами. В частности, обратите внимание на характеристику контрольных сумм и выбор провайдера основного правила сортировки в кластере, который вы будете обновлять. Если pg_upgrade создаст какие-либо скрипты SQL в текущем каталоге, выполните их для завершения обновления.
Если вы выбираете вариант с выгрузкой/восстановлением данных, не забудьте при выгрузке добавить ключ --add-collprovider, чтобы для обновляемой базы данных был установлен правильный провайдер основного правила сортировки.
Понять, какое правило сортировки является основным в старом кластере и какой провайдер оно использует, можно по значению datcollate для базы данных template0 в каталоге pg_database. Если вы производите обновление с версии, в которой провайдер основного правила сортировки не задан, опустите указание провайдера при переходе с предыдущих версий Postgres Pro или выберите провайдер libc при переходе с ванильного PostgreSQL.
Вследствие изменений в реализации исключения дубликатов в индексах-B-деревьях, некоторые ранее сжатые индексы могут перестать поддерживать такое исключение, как описано в Подразделе 62.4.2. Если вы воспользуетесь утилитой pg_upgrade, она объявит такие индексы нерабочими и создаст скрипт reindex_non_equalimage_btree.sql, который надо будет запустить для завершения обновления.
Помимо этого учтите описанные ниже особенности обновления, связанные с изменениями в использовании правил сортировки.
В Windows инсталляции Postgres Pro могли содержать базы данных с основным правилом сортировки на базе ICU, имя которого имело синтаксически правильный формат языка BCP 47, но неправильный код языка или другие параметры, в результате чего это правило сортировки оказывалось недействительным для ICU.
Если эта проблема затрагивает вашу базу данных template0, при попытке инициализировать новый кластер с тем же правилом сортировки вы получите следующее сообщение об ошибке: failed to get the canonical name for collation locale (не удалось получить каноническое имя для локали правила сортировки). В этом случае выполнить обновление можно только путём выгрузки/восстановления данных, задав для нового кластера подходящую локаль для выбранного провайдера правил сортировки.
Если эта проблема затрагивает другие базы данных, вы получите то же сообщение об ошибке, что и при попытке создания в Postgres Pro нового кластера с некорректным правилом сортировки. Вы можете попытаться решить эту проблему следующим образом:
Выгрузите базу данных, используя pg_dump; при этом необходимо указать параметры --create и --format=plain.
Смените в выгруженном файле провайдер основного правила сортировки с '@icu' на '@libc'.
Восстановите изменённое содержимое базы в psql для завершения обновления. Эта операция может прерваться ошибкой, если окажутся нарушенными какие-либо ограничения, зависящие от правил сортировки в базе данных. В этом случае вы можете попытаться разрешить эти проблемы вручную или обратиться к службе поддержки.
В некоторых особых случаях при выгрузке/восстановлении данных вы можете столкнуться с нарушением ограничений в восстанавливаемых базах данных. В частности:
Если в инсталляции Postgres Pro версии 9.6 или ниже содержались индексы или ограничения, зависящие от правил сортировки, отличных от основного правила сортировки БД, а также от C или POSIX в базах данных с многобайтными кодировками, индексы и ограничения в таких базах могли оказаться несогласованными при обновлении до Postgres Pro версии 10 или выше. В Windows эта ситуация также могла иметь место, если база данных с многобайтной кодировкой содержала индексы или ограничения, зависящие от основного правила сортировки с полным именем "Russian_Russia[. или кодировка]""English_United States[..кодировка]"
В Windows у кластеров Postgres Pro 10 с основным правилом сортировки на базе ICU локаль правила сортировки может не совпадать с локалью соответствующего правила сортировки libc.
Когда вы используете программу pg_upgrade, она объявляет такие индексы и ограничения нерабочими и создаёт для их исправления файлы reindex_text_indexes.sql и validate_text_constraints.sql, соответственно. Для завершения обновления вам надо будет выполнить эти скрипты.