Когда мы говорим о надежности и гибкости PostgreSQL, мы редко имеем в виду только само ядро СУБД. Настоящая суперсила Postgres кроется в продуманной архитектуре расширений и вспомогательных утилит. Благодаря хукам и разделяемым библиотекам инженеры могут годами адаптировать базу под самые жесткие корпоративные требования: от аудита безопасности по стандартам PCI DSS до прямого вмешательства в логику планировщика запросов. На днях сообщество PostgreSQL синхронно обновило четыре ключевых инструмента администрирования, закрывая сразу несколько застарелых эксплуатационных болей.
Разберем, какие практические возможности появились в свежих релизах и как они влияют на надежность продакшен-кластеров.
credcheck 6.0
Модуль credcheck от Жиля Дарольда (Gilles Darold / HexaCluster) давно стал де-факто стандартом для проектов, которым необходим строгий аудит учетных записей: проверка сложности паролей, блокировка при переборе и отслеживание сессий в духе классических Unix-файлов wtmp и команды last(1).
Главная новость релиза 6.0 — полноценная интеграция механизма max_auth_failure с пулером соединений PgBouncer. Раньше при использовании PgBouncer в режиме пулинга транзакций перехват неудачных попыток входа часто давал ложные срабатывания или не блокировал атакующий IP-адрес вовремя. Теперь аудит работает бесшовно. Кроме того, внутренняя структура хранения истории паролей переведена на отображаемый в память файл (mmap), что кратно снизило оверхед по памяти.
Появилась и полезная функция pg_check_password() для предварительной проверки стойкости пароля прямо из клиентского кода:
-- Обновление версии расширения в кластере
ALTER EXTENSION credcheck UPDATE TO '6.0';
-- Проверка кандидатного пароля без изменения настроек учетной записи
SELECT pg_check_password('analyst_user', 'Str0ng!P@ssw0rd2026');
-- Установка минимального срока действия пароля (в днях) для новых ролей
SET credcheck.password_valid_min = 7;
Поскольку библиотека credcheck перехватывает служебные хуки ядра и подключается через параметр shared_preload_libraries, одного выполнения команды ALTER EXTENSION недостаточно — для применения обновленной shared library потребуется полный перезапуск службы PostgreSQL (pg_ctl restart).
pg_hint_plan 1.9.0
Оптимизатор запросов PostgreSQL опирается на стоимостную модель (Cost-Based Optimizer), но на сложных аналитических объединениях с сотнями тысяч строк статистика иногда ошибается. В таких ситуациях библиотека pg_hint_plan позволяет жестко зафиксировать желаемый план выполнения через специальные комментарии в теле SQL-запроса.
В релизе 1.9.0 представлена официальная поддержка готовящейся ветки PostgreSQL 19, добавлены новые стратегии генерации путей (Path Generation Strategies, PGS) и решена давняя проблема с зацикливанием парсера при обработке мультизапросных строк:
-- Принудительное сканирование по индексу и соединение методом HashJoin
/*+
SeqScan(t1)
IndexScan(t2 t2_created_at_idx)
Leading((t1 t2))
HashJoin(t1 t2)
*/
SELECT t1.id, t1.name, t2.status, t2.created_at
FROM orders t1
JOIN order_events t2 ON t1.id = t2.order_id
WHERE t2.created_at >= '2026-10-01';
Для команд, которые уже тестируют совместимость своих сервисов с PostgreSQL 19 RC, это критически важное обновление. Ранее мы уже обозревали, как пульсирует экосистема, в материале Пульс экосистемы PostgreSQL: патчи безопасности PgBouncer, защита ODBC и свежие утилиты, и текущие апдейты логично продолжают эту линию.
pg_utl_smtp 2.0
Расширение pg_utl_smtp появилось как часть открытого стека миграции HexaRocket, призванного упростить переезд с проприетарных СУБД вроде Oracle и Microsoft SQL Server на PostgreSQL. Исторически в них широко использовались пакеты UTL_SMTP и процедура sp_send_dbmail для отправки системных email-уведомлений прямо из триггеров и хранимых процедур.
В версии 2.0 появилась долгожданная настройка pg_utl_smtp.asynchronous. Теперь отправка нотификаций не блокирует выполнение транзакции: письмо ставится в локальную неблокирующую очередь. Кроме того, внедрена полноценная поддержка шифрованных соединений по протоколу TLS непосредственно перед началом SMTP-хендшейка, что позволяет использовать корпоративные почтовые шлюзы без промежуточных незащищенных релеев.
pgBackRest 2.60.0
Для физического резервного копирования терабайтных баз данных pgBackRest остается признанным золотым стандартом. Версия 2.60.0 приносит фундаментальное изменение для гарантий целостности данных: опцию checksum-page-error.
Раньше, если в процессе восстановления из бэкапа обнаруживался блок с поврежденной контрольной суммой (page checksum), утилита могла продолжить накат данных, оставляя администратора в неведении о скрытой деградации файловой системы. Теперь pgBackRest по умолчанию немедленно останавливает процедуру восстановления с критической ошибкой, предотвращая запуск поврежденного кластера в продакшен. Дополнительно в релизе реализована аутентификация через Workload Identity Federation для Google Cloud Storage (GCS) и добавлена поддержка библиотеки OpenSSL 4.
Синхронный выход этих релизов наглядно показывает вектор развития всей экосистемы: ужесточение требований к безопасности данных, отказ от синхронных блокировок в пользу очередей и глубокая подготовка инфраструктурных инструментов к выходу PostgreSQL 19. Если ты администрируешь базы в продакшене, самое время запланировать плановые работы по обновлению утилит в ближайшие окна обслуживания.