PGConf.Russia 2025

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

Проведем обзор возможностей утилиты резервного копирования pg_probackup3. 

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

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

Эти проблемы касались поддержки автономных транзакций, пакетных переменных и ряда других особенностей. В чём особенность pg_settings? Почему нам необходимы именно автономные транзакции и причём тут HOLD-курсоры? Это и многое другое мы расскажем в нашем докладе, а также поделимся своим опытом внедрения Postgres Pro Enterprise.

Доклад содержит рассмотрение двух случаев длительного выполнения create database в PostgreSQL 11, которые в кластерной конфигурации Corosync/Pacemaker приводили к переключению нод из-за таймаута мониторинга от кластерного ПО. Первый случай связан с большим размером shared buffers, а второй — с использованием опции WITH OWNER при создании БД и большим размером системной таблицы pg_shdepend (особенность использования ПО jBPM).