PGConf.Russia 2025

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

Консолей администратора существует множество — от старорежимного DBeaver до всепроникающего pgAdmin. Тем не менее, мы решили сделать ещё одну. Зачем?

Из доклада вы узнаете:

— Как одна инсталляция может обслуживать несколько десятков тысяч экземпляров БД 

— Сколько пользователей может поддержать консоль 

— Как провести инвентаризацию инфраструктуры и не сойти с ума

— Как вписаться в привычное окружение, не заставляя переделывать всё с нуля

— Как построить модель безопасности, чтобы тебе доверяли ведущие банки и телеком-операторы

— И наконец — как потрогать всё это руками

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