2026 PostgreSQL 14 перед прекращением поддержки: как проверить совместимость расширений?

По данным официальной политики поддержки PostgreSQL, поддержка PostgreSQL 14 заканчивается 12 ноября 2026 года. Если вы обслуживаете эту версию, не переключайте производство только из-за приближения даты: сначала подтвердите, что целевая среда предоставляет нужные расширения и совместимые пути обновления, а затем проверьте приложение в изоляции.

Подходит: DBA, разработчикам и руководителям платформы, которые поддерживают собственную базу PostgreSQL 14 и отвечают за её расширения, миграцию и восстановление.
Не подходит: тем, кто ищет выбор между PostgreSQL 17 и 18 или полный учебник по переносу кластера: здесь рассматривается именно поиск блокеров совместимости расширений.

Последнее обновление: 28 октября 2026 года. Дата окончания поддержки сверена с официальной страницей жизненного цикла PostgreSQL и объявлением о выпуске PostgreSQL 14.24: страница поддержки, объявление о выпуске.

Дата окончания поддержки и готовность расширений — разные проверки

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

Проверка должна отвечать на отдельные вопросы:

• Какие расширения установлены в каждой базе кластера, и какие версии указаны?
• Есть ли файлы этих расширений на целевом сервере PostgreSQL?
• Доступен ли подходящий путь обновления с текущей версии расширения?
• Продолжает ли приложение вызывать предоставляемые расширением функции, операторы или типы?
• Можно ли восстановить резервную копию, если проверка или переключение завершится неудачно?

Не смешивайте эти вопросы с выбором между целевыми версиями PostgreSQL: сначала определите план перехода, а в этой проверке используйте его целевую среду. До тех пор, пока список расширений не сопоставлен с установленными пакетами и не проверено приложение, календарное давление — не основание для производственного переключения.

Инвентаризация: установленное расширение — ещё не весь список зависимостей

PostgreSQL хранит сведения об установленных расширениях в системном каталоге pg_extension. Документация описывает его поля и связь с конкретной базой; поэтому проверку нужно повторить при подключении к каждой базе, а не ограничиваться одной базой или настройками кластера. Для просмотра установленного набора можно также использовать команду \dx в клиенте psql. Описание каталога pg_extension

SELECT
    e.extname,
    e.extversion,
    e.extnamespace::regnamespace AS schema_name
FROM pg_extension AS e
ORDER BY e.extname;

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

На целевом сервере можно отдельно запросить доступные расширения и версии:

SELECT
    name,
    default_version,
    installed_version,
    comment
FROM pg_available_extensions
ORDER BY name;

Представление pg_available_extensions отражает сведения об расширениях, доступных в данной установке PostgreSQL; его описание доступно в официальной документации. Если в результатах целевой среды нет имени из инвентаризации, выясните причину до перехода: нужный пакет может не быть установлен, быть собран для другой версии сервера или предоставляться другим способом. Не трактуйте отсутствие строки как доказательство, что расширение не используется в текущей базе.

Чтобы не принять список установленных расширений за полный перечень зависимостей, сопоставьте его с источниками вне каталога:

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

В PostgreSQL расширение состоит не только из записи в каталоге: важны доступные файлы и определённые для расширения SQL-объекты, а механизм их установки и обновления описан в документации по расширениям. Поэтому один успешный запрос к каталогу не заменяет проверку кода и сценариев развёртывания.

Отсутствует файл или путь обновления — найдите точный блокер

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

Перед выполнением pg_upgrade используйте режим проверки с путями к старым и новым исполняемым файлам и каталогам данных, соответствующими вашей установке. Например, общая форма команды выглядит так:

/path/to/new/bin/pg_upgrade \
  --check \
  --old-bindir=/path/to/old/bin \
  --new-bindir=/path/to/new/bin \
  --old-datadir=/path/to/old/data \
  --new-datadir=/path/to/new/data

Это шаблон, а не готовая команда для любой системы: замените пути на фактические и сверяйте параметры с документацией для выбранной целевой версии. В ней описаны назначение и ограничения pg_upgrade; например, проверочный режим не является тестированием прикладной логики. См. документацию PostgreSQL 17 по pg_upgrade и документацию PostgreSQL 18 по pg_upgrade.

Если проверка указывает на расширение, не удаляйте его сразу ради прохождения миграции. Уточните, какие типы, функции, операторы, индексы и таблицы оно предоставило, и какие из них использует приложение. Удаление или изменение объектов в production без проверки может устранить видимый блокер, но создать ошибку в рабочем процессе. Сначала повторите изменение в тестовой среде, проверьте запросы и подготовьте способ возврата.

Функциональный тест и отдельное обновление расширения

Даже когда целевой сервер предоставляет нужное расширение, отдельно выясните, требуется ли обновлять его после перехода PostgreSQL. Команда ALTER EXTENSION ... UPDATE применима, если для установленной и целевой версий предусмотрен подходящий путь обновления. Команда не создаёт такой путь сама и не заменяет инструкции сопровождающего. Описание ALTER EXTENSION

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

В журнал испытания внесите версию PostgreSQL, версию расширения, использованные файлы установки, команды и SQL, результаты тестов и наблюдавшиеся ошибки. Запишите и процедуру отката. Если проблема проявилась только в конкретном приложении, сохраните минимальный воспроизводимый пример, а не ограничивайтесь записью «расширение не работает».

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

Частые вопросы перед PostgreSQL 14 и pg_upgrade

Как проверить установленные расширения до обновления? Подключайтесь к каждой базе отдельно, выполните запрос к pg_extension и сохраните версии. Затем проверьте целевой сервер через pg_available_extensions, сравните результаты и дополните их проверкой кода и сценариев развёртывания. Так вы получите перечень для анализа, но не полную карту прикладных зависимостей без проверки приложения.

Можно ли доверять одному и тому же имени расширения? Нет. На целевом сервере должны быть доступны соответствующие файлы, а установленная версия должна иметь подходящий путь обновления. Уточните эти условия по документации издателя и подтвердите установку в изолированной среде. Неизвестный путь — это пункт, который нужно разрешить до производственного переключения, а не основание считать расширение совместимым.

Что делать, если pg_upgrade обнаружил проблему? Сохраните полный вывод проверки и журналы, сопоставьте сообщение с инвентаризацией расширений, затем определите, не хватает ли файлов, пути обновления или необходимых объектов. Проверьте исправление на копии среды. Проход инструмента после исправления не отменяет тестирования функций приложения и процедуры восстановления.

Нужно ли обновлять расширение после перехода? Проверьте это отдельно для каждого расширения и каждой базы. Если целевая версия требует перехода расширения и издатель документирует путь, выполните его сначала в тестовой среде, затем проверьте функции и объекты. Не удаляйте расширение только ради успешного перехода: сначала докажите, что приложение не зависит от предоставленных им возможностей.

Перед переключением: условия готовности и выбор целевой среды

Для производственного переключения должны быть выполнены все условия: перечень расширений собран по базам; целевая среда предоставляет необходимые компоненты; обновление расширений проверено; приложение прошло тесты; резервная копия восстановлена в тестовой среде; предусмотрены действия при неудаче. Если хотя бы один критический пункт не проверен, отложите переключение, пока не будет готова воспроизводимая проверка или согласованный план обхода.

Используйте следующую развилку решения:

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

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

Если вы одновременно планируете собственную целевую среду, учитывайте фактическое распределение памяти и дисков под базу, журналы и резервирование; разбор того, как сопоставлять ресурсы памяти и дисков, поможет не смешивать требования СУБД с требованиями копирования. В конфигурациях OSFP Cloud доступны варианты памяти 128 или 256 ГБ, прямое подключение NVMe и Linux-системы с доступом по SSH; конкретные условия и состав оборудования проверяйте в описании OSFP Cloud. Это сведения о среде размещения, а не обещание установки расширений, сопровождения базы или выполнения миграции за вас. Для управления сервером заранее проверьте также порядок SSH-доступа.

Выбирая между управляемой базой, общей виртуальной машиной и выделенным сервером, сопоставляйте не только ежемесячный счёт, но и обязанности по обновлениям, резервному копированию и тестированию. Общая виртуальная среда может ограничивать доступ к системным файлам расширений и усложнять контроль над ресурсами; управляемая услуга снимает часть операционных задач, но не отменяет проверку специфических расширений приложения. Выделенная машина подходит, если вам нужны контроль над установкой компонентов и стабильная среда для длительной работы, а команда готова самостоятельно обслуживать PostgreSQL, резервные копии и восстановление. У OSFP Cloud доступна аренда выделенных AMD-серверов, но сам факт аренды не создаёт отказоустойчивость: оборудование не заменяет программное зеркало или репликацию и копию данных вне сервера. Если производственное переключение уже планируется, сначала завершите репетицию и проверку восстановления, а затем выбирайте целевые ресурсы по фактическому профилю нагрузки.

Вопросы

Как проверить, какие расширения установлены в PostgreSQL 14?

Подключитесь к каждой базе отдельно и запросите каталог pg_extension: он показывает установленные расширения и их текущие версии. Затем сравните список с представлением pg_available_extensions на целевом сервере. Одного SQL-запроса недостаточно: дополнительно проверьте миграционные сценарии, определения объектов и код приложения, потому что использование функции расширения не всегда очевидно из списка установленных пакетов.

Можно ли считать расширение совместимым, если оно называется так же в новой версии?

Нет. Совпадение имени не подтверждает, что в целевой установке есть подходящие файлы расширения, поддерживается установленная версия или существует путь обновления. Сверьте доступные версии и сведения издателя расширения, затем проверьте установку и используемые приложением функции в отдельной среде. Если сведений о совместимости нет, зафиксируйте это как нерешённый блокер, а не как подтверждение.

Что именно проверяет pg_upgrade при переходе между основными версиями?

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

Нужно ли обновлять расширения отдельно после перехода PostgreSQL?

Это зависит от расширения и доступного пути обновления. После перехода проверьте установленную и целевую версии в каждой базе; если издатель предоставляет подходящий путь, выполните обновление расширения по его документации и проверьте результат. Не удаляйте и не переустанавливайте расширение автоматически: созданные им типы, функции, индексы и другие объекты могут использоваться приложением.