Обзор PostgreSQL 19 RC: что вошло в релиз, а что отозвали

15 октября 2026 года PostgreSQL Global Development Group выпустила первый релиз-кандидат PostgreSQL 19. Финальная версия запланирована на 19 ноября 2026 года, второй кандидат — на 12 ноября. Релиз большой, но с оговоркой: часть громких функций из анонса беты отозвали в последние недели. Обзор для тех, у кого на PostgreSQL работают CRM, интернет-магазины и учётные системы — в том числе 1С на PostgreSQL.

Что нового в PostgreSQL 19

Производительность:

• вставка в таблицы с внешними ключами — до 2 раз быстрее;
• автоочистка (autovacuum) может работать параллельными процессами и получила новую систему приоритетов таблиц;
• число процессов асинхронного ввода-вывода подстраивается автоматически;
• новые оптимизации планировщика: anti-join, расширенная инкрементальная сортировка, «жадная» агрегация;
• лучше масштабируется LISTEN/NOTIFY при множестве каналов.

Для разработчиков:

• `INSERT ... ON CONFLICT DO SELECT ... RETURNING` возвращает уже существующую строку при конфликте — удобно для «найти или создать»;
• `GROUP BY ALL` группирует по всем неагрегированным столбцам;
• `IGNORE NULLS` для оконных функций `lead`, `lag`, `first_value` и других;
• команда `REPACK` с опцией `CONCURRENTLY` заменяет `VACUUM FULL` и `CLUSTER`;
• `WAIT FOR LSN` позволяет дождаться, пока реплика догонит основной сервер;
• расширение `pg_plan_advice` помогает зафиксировать решения планировщика.

Безопасность и наблюдаемость:

• один сервер может отдавать разные TLS-сертификаты по имени хоста (SNI, файл `pg_hosts.conf`);
• предупреждение об истечении пароля, по умолчанию за 7 дней;
• новые представления `pg_stat_lock` и `pg_stat_recovery`, опция `IO` в `EXPLAIN ANALYZE`.

Логическая репликация теперь переносит значения последовательностей и включается без перезапуска даже при `wal_level = replica`.

Что отозвали из релиза

По данным Дмитрия Фонтейна (tapoueh.org), из ветки 19 после выхода беты убрали несколько функций из-за найденных проблем:

• `ALTER TABLE ... MERGE PARTITIONS` и `SPLIT PARTITION` — отозваны 27 августа;
• запросы к графам свойств SQL/PGQ — 7 сентября;
• функции `pg_get_role_ddl()` и аналоги — 12 сентября;
• `UPDATE` и `DELETE` с `FOR PORTION OF` — 15 сентября;
• включение контрольных сумм данных без остановки — 16 сентября.

Эти возможности остались в ветке разработки 20-й версии. Автор предупреждает: в материалах о релизе они ещё могут упоминаться, поэтому проверяйте функции на реальной сборке, а не по анонсам.

Что изменится без вашего участия

Самое заметное — JIT. Если у вас тяжёлые аналитические запросы и они полагались на JIT, после обновления их скорость может измениться. Включить обратно можно параметром `jit = on`.

Смена сжатия на lz4 влияет на размер хранения и нагрузку на процессор — обычно в лучшую сторону, но для больших баз это стоит замерить. Если вы явно задавали `max_locks_per_transaction`, по совету tapoueh.org значение стоит удвоить.

Подводные камни при обновлении

• Индексы `btree_gist` для типов `inet` и `cidr` нужно перестроить до `pg_upgrade` — иначе утилита откажется работать.
• Если на старом сервере было `standard_conforming_strings = off`, сделайте выгрузку свежим `pg_dump`.
• Пароли в md5 стоит заранее перевести на `scram-sha-256`.
• Символы перевода строки в именах баз, ролей и табличных пространств теперь запрещены.

Как подготовить мажорное обновление

Переход между мажорными версиями PostgreSQL — не «нажать кнопку». Его готовят как маленький проект.

1. Инвентаризация. Список баз, расширений (PostGIS, pg_trgm, btree_gist и других) и их версий. Каждое расширение должно поддерживать новую версию сервера.
2. Тестовая копия. Восстановите свежую резервную копию на отдельном сервере с новой версией и прогоните приложение: формы, отчёты, обмены.
3. Замер окна работ. `pg_upgrade` в режиме ссылок занимает минуты, выгрузка и загрузка большой базы — часы. Замерьте на копии, чтобы назначить реальное окно.
4. Статистика. После обновления запустите сбор статистики, иначе первые часы запросы могут идти медленнее.
5. План отката. Резервная копия, проверенная восстановлением, и инструкция, как вернуться на старую версию.

Для интернет-магазина или CRM разумное окно — ночь с минимальной нагрузкой и предупреждением клиентов о технических работах.

Стоит ли обновляться

1. Рабочие системы. Ждать финала 19 ноября и первых исправлений — минимум 19.1. Мажорное обновление делается через `pg_upgrade` или выгрузку и загрузку, с резервной копией и окном работ.
2. PostgreSQL 14. Обновляться нужно в любом случае: поддержка 14-й ветки заканчивается 12 ноября 2026 года. Разумная цель — 17 или 18, а не только что вышедшая 19.
3. Тестовые среды. RC1 можно ставить уже сейчас и проверять свои запросы, особенно аналитические — из-за выключенного JIT.
4. 1С на PostgreSQL. Переходите только на версии, которые поддерживает ваша версия платформы 1С: для неё используются специальные сборки PostgreSQL, и их выпуск отстаёт от основного проекта.

Наше мнение

Мы считаем PostgreSQL 19 сильным релизом для нагруженных систем: параллельная автоочистка, ускорение внешних ключей и `REPACK CONCURRENTLY` решают реальные проблемы больших таблиц. Отзыв нескольких функций в последний момент — признак зрелого процесса, а не провала. Что мы советуем клиентам: не гнаться за «нулевой» версией, а сначала закрыть устаревшие ветки, и только потом планировать переход на 19 — ориентировочно весной 2027 года, после пары корректирующих выпусков.