СУБД Postgres Pro

Самая популярная российская СУБД для Enterprise-задач

Попробовать Узнать больше

Postgres Pro доверяют


ПРОИЗВОДИТЕЛЬНОСТЬ


БЕЗОПАСНОСТЬ


НАДЕЖНОСТЬ


УДОБСТВО ЭКСПЛУАТАЦИИ

Планы развития

Компания Postgres Pro ставит целью создание интеллектуальной облачной СУБД для больших данных, для чего ведет исследования в прорывных областях.

СУБД Postgres Pro уже обладает рядом возможностей, воcтребованных в эпоху Индустрии 4.0.

Распределенные и отказоустойчивые системы

Применение распределенных технологий существенно повышает производительность и надёжность СУБД при сохранении гарантий транзакционной целостности данных.

Доступность в облаках

Собственное решение для организации сервисов типа DBaaS даёт возможность заказчикам гибко управлять выделением ресурсов в корпоративных облаках.

Адаптивная СУБД

Использование технологий машинного обучения и внутренней обратной связи увеличивает эффективность внутренних механизмов СУБД, что снижает время исполнения отдельных SQL‑запросов и повышает производительность в целом.

Поддержка и эксплуатация СУБД

Доверьте заботу о СУБД профессионалам.
Мы предлагаем полный спектр услуг в области управления базами данных на основе Postgres.

Наши партнеры

В числе партнеров Postgres Pro свыше 50 компаний, включая технологических партнеров, дистрибьюторов и интеграторов.

Наши партнёры Стать партнером

Система управления базами данных Postgres Pro Enterprise для высоконагруженных систем. Выдерживает нагрузку 1 млн. транзакций в секунду при размере базы данных 150 ТБ.

Узнать больше

Текущая версия

Версия Postgres Pro Enterprise 16.4.1 выпущена

E.1. Postgres Pro Enterprise 16.4.1 #

Дата выпуска: 2024-09-09

E.1.1. Обзор #

Этот выпуск основан на PostgreSQL 16.4 и Postgres Pro Enterprise 16.3.2. Все изменения, унаследованные от PostgreSQL 16.4, описаны в Замечаниях к выпуску PostgreSQL 16.4. По сравнению с Postgres Pro Enterprise 16.3.2 эта версия также содержит следующие изменения:

  • Увеличена производительность поиска сегментов за счёт внедрения новой стратегии, позволяющей быстрее определять последний сегмент.

  • Снижено количество ненужных попыток перепланирования за счёт добавления триггера потребления памяти рабочим процессом, значение которого определяется параметром конфигурации replan_memory_limit, и изменения поведения процесса перепланирования. Теперь такое поведение срабатывает в зависимости от количества обработанных кортежей узлов.

  • Реализовано взаимодействие параметра PASSWORD_GRACE_TIME профиля с атрибутом VALID UNTIL роли. Теперь, если заданы оба, будет выводиться предупреждение об истечении срока действия пароля.

  • Предотвращены потенциальные задержки аутентификации из-за блокировок, вызванных тем, что данные о времени последнего входа роли не обновлялись, если для параметра USER_INACTIVE_TIME профиля этой роли было установлено значение UNLIMITED (за подробностями обратитесь к Разделу 54.40).

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

  • Исправлена ошибка обработки статистики автономных транзакций. Ранее изменения статистики сохранялись только при фиксировании и автономной, и родительской транзакции. Никаких сбоев из-за этого безобидного упущения не наблюдалось.

  • Устранена проблема с параметрами вложенного цикла, из-за которой указание Memoize постоянно очищало кеш. Это исправление ускоряет выполнение запросов.

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

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

  • Устранена проблема с замораживанием 64-битных идентификаторов мультитранзакций, которая могла проявляться в ошибках уровня PANIC, таких как «xid XXX does not fit into valid range for base YYY» (xid XXX не попадает в допустимый диапазон для базы YYY) во время автоочистки.

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

  • Устранена проблема, которая могла проявляться в ошибках вида «invalid FSM request size» (недопустимый размер запроса FSM). Код был скорректирован с учётом изменений в структуре страниц кучи, что исключило зависимость от константы, связанной с максимальным свободным пространством на странице кучи, в случаях, где это не применимо.

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

  • Устранена ошибка в ANALYZE, которая могла возникать из-за невозможности отобразить системный каталог pg_statistic. Если в базе данных есть индексы со столбцами INCLUDE, после обновления Postgres Pro рекомендуется ещё раз выполнить ANALYZE для этих столбцов, чтобы это исправление применилось.

  • Добавлена поддержка ОС Альт 11.

  • Драйвер ODBC обновлён до версии 16.00.0005.

  • Улучшена функциональность встроенной отказоустойчивости — включены следующие исправления и усовершенствования:

    • Расширение biha обновлено до версии 1.3.

    • Оптимизирована логика автоматической синхронизации узлов. Теперь если на узле для параметра конфигурации biha.autorewind установлено значение false и временные линии кластера разошлись, узел перестаёт принимать записи WAL после перехода в состояние NODE_ERROR. Согласно новой логике, для выполнения запросов на узле удалите biha из shared_preload_libraries и/или выполните синхронизацию вручную. Результаты синхронизации теперь можно проверить в поле rewind_state файла biha.state.

    • Оптимизировано поведение синхронного узла-рефери, работающего в режиме referee_with_wal. Теперь оно зависит от значения параметра конфигурации synchronous_commit.

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

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

    • Устранены утечки памяти в bihactl.

  • Расширение citus обновлено до версии 12.1.5.1, которая поддерживает возможность использовать его со включённым параметром конфигурации enable_group_by_reordering.

  • Расширение dbms_lob обновлено до версии 1.2, которая поддерживает чтение и запись блоков до 1 ГБ, раньше размер блока не мог превышать 32 КБ.

  • Добавлено расширение hypopg, обеспечивающее поддержку гипотетических индексов в Postgres Pro.

  • Обновлено расширение mchar для устранения ошибки, из-за которой игнорировались управляющие символы при сравнении строк типов данных mchar и mvarchar.

  • Реализована возможность замедлять выполнение транзакций на узле-доноре в расширении multimaster с помощью параметра конфигурации multimaster.tx_delay_on_slow_catchup . Это полезно, когда отстающий узел навёрстывает состояние узла-донора и не может быстро применять изменения.

  • Расширение pg_filedump обновлено до версии 17.0, в которой были исправлены некоторые ошибки и появились новые возможности. В частности, содержимое метастраниц для индексов GIN и SP-GiST теперь отображается корректно, а также устранена проблема нехватки памяти для кодирования и распаковки.

  • Обновлено расширение pg_proaudit. Включены следующие исправления и усовершенствования:

    • Улучшена производительность и добавлен параметр pg_proaudit.max_rules_count, позволяющий указать максимально допустимое количество правил.

    • Устранена ошибка для корректной поддержки имён баз данных, содержащих символы верхнего регистра, при работе функции pg_proaudit_set_rule.

  • Приложение pg_probackup обновлено до версии 2.8.3 Enterprise, в которую были включены следующие исправления:

    • Исправлена проверка резервных копий для баз данных, содержащих OID более 10^9. Ранее в таких случаях статус проверки мог отображаться некорректно.

    • Устранена ошибка, которая могла возникать при запуске pg_probackup от имени пользователя, включённого в группу postgres, если в базе данных использовалась CFS.

  • Расширение pgpro_rp обновлено до версии 1.1, которая поддерживает группы назначений планов. Администратор баз данных теперь может создавать группы назначений планов для разных ролей, чтобы управлять приоритизацией ресурсов среди большого числа пользователей баз данных.

  • Расширение pgpro_sfile обновлено до версии 1.2, в которой добавлена функция sf_md5, вычисляющая MD5-хеш для объекта sfile.

  • Расширение pgvector обновлено до версии 0.7.4.

  • Исправлено некорректное поведение pg_wait_sampling при использовании с расширенным протоколом запросов.

  • Модуль sr_plan был обновлён, в новой версии улучшена производительность и добавлены новые возможности. Основные изменения перечислены ниже:

    • Добавлен параметр конфигурации sr_plan.sandbox, который позволяет тестировать и анализировать запросы без влияния на работу узлов путём резервирования для них отдельных зон разделяемой памяти.

    • Добавлены три параметра конфигурации sr_plan.auto_capturing, sr_plan.max_captured_items и sr_plan.max_consts_len, которые позволяют настраивать отслеживание запросов.

    • Добавлено представление sr_captured_queries, которое показывает информацию об отслеживаемых в сеансах запросах.

    • Добавлена функция sr_captured_clean, которая удаляет все записи из представления sr_captured_queries.

    • Параметр конфигурации sr_plan.max переименован в sr_plan.fs_ctr_max.

    • Ключ queryid заменён на sql_hash, что отражает новую логику идентификации запросов.

  • Обновлено расширение utl_http. Теперь поддерживаются HTTP-методы PUT, UPLOAD, PATCH, HEAD, OPTIONS, DELETE, TRACE, а также любые пользовательские HTTP-методы.

E.1.2. Миграция на версию 16.4.1 #

Если вы производите обновление выпуска Postgres Pro Enterprise, базирующегося на той же основной версии PostgreSQL, достаточно просто установить новый выпуск в текущий каталог инсталляции.

Важно

Если вы обновляете встроенный отказоустойчивый кластер с Postgres Pro Enterprise версии 16.3 или ранее до Postgres Pro Enterprise версии 16.4, выполните следующие действия:

  1. Для параметров nquorum и minnodes установите значение больше числа узлов в кластере, чтобы избежать непредвиденных выборов лидера и чтобы его состояние изменилось с LEADER_RW на LEADER_RO. Выполните этот шаг при помощи функции biha.set_nquorum_and_minnodes. После этого подождите, пока узлы-последователи догонят узел-лидер по числу записей WAL. Это можно проверить в представлении pg_stat_replication с узла-лидера — столбец replay_lag будет содержать значение NULL для всех узлов-последователей.

  2. Остановите узел-последователь при помощи команды pg_ctl.

  3. Обновите сервер узла-последователя.

  4. Запустите узел-последователь при помощи команды pg_ctl.

  5. Повысьте статус обновленного узла-последователя до лидера при помощи функции biha.set_leader.

  6. Обновите серверы оставшихся узлов-последователей и старого лидера.

  7. Повысьте статус старого узла-лидера при помощи функции biha.set_leader.

  8. Для параметров nquorum и minnodes установите значения, которые использовались до начала обновления Postgres Pro Enterprise. Выполните этот шаг при помощи функции biha.set_nquorum_and_minnodes.

Обратите внимание, что если узел с сервером Postgres Pro Enterprise версии 16.1 перешёл в состояние NODE_ERROR, другие узлы могут «видеть» его состояние некорректно, например, как REFEREE. В этом случае рекомендуется остановить узел, обновить сервер на нём, синхронизировать узел с помощью pg_rewind и запустить снова.

Важно

При обновлении отказоустойчивого кластера с Postgres Pro Enterprise версии 16.3.x или ниже сначала отключите автоматическое аварийное переключение узлов, если оно было включено, и обновите все резервные серверы, затем обновите ведущий сервер, повысьте резервный сервер до ведущего и перезапустите бывший ведущий сервер (возможно, с использованием pg_rewind).

Если вы создаёте резервные копии с помощью pg_probackup и ранее обновили его до версии 2.8.0 Enterprise или 2.8.1 Enterprise, обязательно обновите его до версии 2.8.2 Enterprise или выше и сделайте полную резервную копию базы данных после обновления, поскольку резервные копии, созданные с использованием этих версий, могут быть повреждены. Чтобы проверить, повреждены ли резервные копии, созданные с помощью версий 2.8.0 или 2.8.1, можно использовать версию 2.8.2.

Если вы обновляете встроенный отказоустойчивый кластер с Postgres Pro Enterprise версий 16.1 и 16.2 до Postgres Pro Enterprise версии 16.3, выполните следующие действия:

  1. Остановите узел-последователь при помощи команды pg_ctl.

  2. Обновите сервер узла-последователя.

  3. Запустите узел-последователь при помощи команды pg_ctl.

  4. Повысьте статус обновленного узла-последователя до лидера при помощи функции biha.set_leader.

  5. Обновите серверы оставшихся узлов-последователей и старого лидера.

  6. Повысьте статус старого узла-лидера при помощи функции biha.set_leader.

Обратите внимание, что если узел с сервером Postgres Pro Enterprise версии 16.1 перешёл в состояние NODE_ERROR, другие узлы могут «видеть» его состояние некорректно, например, как REFEREE. В этом случае рекомендуется остановить узел, обновить сервер на нём, синхронизировать узел с помощью pg_rewind и запустить снова.

Для перехода с PostgreSQL, а также с выпуска Postgres Pro Standard или Postgres Pro Enterprise, базирующегося на предыдущей основной версии PostgreSQL, обратитесь к инструкциям по миграции на версию 16.

Подробнее

Закажите тестирование СУБД Postgres Pro

Выберите вариант СУБД для тестирования:






Подписывайтесь на наш ТГ-канал Postgres Professional
Для того, чтобы продолжить запрос, необходимо авторизоваться с использованием корпоративной почты. Сейчас Вы вошли с использованием публичного сервиса электронной почты.

Запросить ПО на тестирование

Тестовые лицензии СУБД Postgres Pro предназначены исключительно для целей разработки, тестирования и ознакомления с возможностями продукта. Использование данных лицензий в коммерческих и производственных целях, а также промышленной эксплуатации не разрешается. Для промышленной эксплуатации необходимо осуществить приобретение коммерческих лицензий.

По истечении срока действия Соглашения Пользователь обязан прекратить использование программного обеспечения.

С полным текстом лицензионного соглашения для тестовых лицензий можно ознакомиться по ссылке.

Вы можете протестировать Продукт ПО, получив безвозмездно право его использования на основании простой (неисключительной) лицензии согласно условиям Соглашения, изложенного ниже.

Если, ознакомившись с Соглашением, Вы согласны соблюдать его условия при использовании Продукта, то Вам необходимо направить в ООО «ППГ» Заявку на тестирование по Форме. По итогам одобрения Заявки Соглашение будет считаться заключенным и вступит в силу с даты направления Правообладателем в личный кабинет Пользователя уведомления об акцепте Заявки и направления ООО «ППГ» на адрес электронной почты, указанный Вами в Заявке, информации для скачивания дистрибутива Продукта.

Получить ПО на тестирование

Пожалуйста, введите данные, чтобы мы могли связаться с Вами:
Заполните фамилию
Заполните имя
Заполните отчество
Заполните E-mail
Заполните вашу должность
Укажите правильный ИНН организации
Укажите название организации
Укажите сайт организации
Выберите профиль компании
Ваш заявка на получение копии ПО для проведения тестирования направлена в службу продаж, ожидайте ответа. Заявка будет обработана в течение 1-го рабочего дня.