PGConf.Russia 2025

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

При переходе с Oracle и других проприетарных систем на PostgreSQL разработчикам приходится адаптировать существующую кодовую PL/SQL-базу под PL/pgSQL. Несмотря на сходство этих двух процедурных языков, значительные различия в их синтаксисе, характеристиках производительности и особенностях экосистемы требуют продуманного подхода к миграции и оптимизации.

В этом докладе сфокусируемся на ключевых различиях между PL/SQL Oracle и PL/pgSQL PostgreSQL, поделимся инсайтами о том, как эффективно адаптировать код во время миграции. 

Особое внимание уделим следующим аспектам:

• Методология компиляции
• Отладка кода
• Обработка исключений
• work_mem
• Массовая загрузка данных

В прошлом году мы сделали встроенную поддержку отказоустойчивости в Postgres Pro Enterprise — BiHA. Наше решение позволяет разворачивать отказоустойчивый кластер Postgres, в котором в случае сбоя пишущего узла новый пишущий узел (лидер) будет выбран автоматически.

При этом возникает проблема перенаправления трафика на нового лидера. Её можно решить с помощью нашего расширения Proxima или внешнего TCP-прокси сервера. И первое, и второе решение были вынуждены периодически опрашивать кластер BiHA для определения пишущего узла.

Как альтернатива, в новой версии BiHA появилась возможность зарегистрировать пользовательские функции, которые будут вызваны при возникновении таких событий в кластере, как смена лидера, добавление/удаление ноды и других. Этот механизм мы назвали пользовательские колбэки. В докладе мы расскажем, как реализованы колбэки и обсудим особенности их использования

Всем известно, что для быстрого обновления PostgreSQL нужно использовать инструмент pg_upgrade. Однако даже в этом случае бывают ситуации, когда невозможно уложиться в какое-то нормальное время обновления. В нашем случае, чтобы выполнить обновление в СУБД PostgreSQL, которое содержит 350 тыс. таблиц, пришлось либо ждать 3 с половиной часа, либо найти другой способ обновления. Мы немного покопались в исходниках утилиты pg_upgrade и нашли вариант, когда процесс обновления можно ускорить в несколько раз. Об этом способе мы вам и расскажем.

НЕОБХОДИМО С СОБОЙ ИМЕТЬ НОУТБУК! Мастер-класс по созданию и конфигурированию отказоустойчивого кластера BiHA.