Релиз PostgreSQL 19 переносится. Формулировка из блога Snowflake прямая: код находится в тяжёлом цикле ревью, крупные фичи откатываются прямо во время беты, многие остальные переписываются.
Beta 4 назначена на 24 сентября 2026, а сам релиз сдвигается с ожидавшейся осени «на недели, а возможно и месяцы».
Звучит как плохая новость. На деле — ровно наоборот, и ниже объясняю почему.
По материалам статьи PostgreSQL 19 release delay and feature reverts (Elizabeth Garrett Christensen, 16 сентября 2026). Разбор мой.
Что откатили
Всего за время беты набралось 53 реверта. Вот одиннадцать самых заметных — вместе с причинами, потому что причины здесь интереснее самих фич.
| Фича | Почему откатили |
|---|---|
| SQL/PGQ (запросы к графам) | Вопросы к самому дизайну и общей готовности |
| ALTER TABLE MERGE/SPLIT PARTITION | Проблемы проектирования, найденные слишком поздно |
| UPDATE/DELETE FOR PORTION OF | Обработка temporal-диапазонов |
| GROUP BY ALL | Не учитывалась сортировка с нестандартной семантикой равенства — выдавал неверные результаты |
| lz4 как TOAST-сжатие по умолчанию | Не вся инфраструктура сборки это поддерживает |
Нетекстовые форматы pg_dumpall | Живые баги, найденные при ревью после коммита |
Каскадирование JSON_TABLE ON ERROR | Баги, обнаруженные при тестировании |
| Fast default для доменов | Требует расширения API методов доступа к таблицам |
| Снапшоты для конкретной БД в логической репликации | Слишком ограниченная функциональность для 19-й |
Учёт вложенных запросов в pg_stat_statements | Синтаксические проблемы при тестировании |
| Онлайновые контрольные суммы данных | Реализация не доведена до конца |
Обратите внимание на четвёртую строку. GROUP BY ALL выдавал неправильные результаты — не падал, не тормозил, а тихо возвращал не то. Это худший класс дефекта для базы данных: приложение работает, отчёты строятся, и никто не знает, что цифры врут.
Ровно для этого и существует бета.
Что остаётся
Релиз похудел, но не опустел:
pg_plan_adviceи подсказки планировщику — давняя больная тема, наконец подступились;- параллельный autovacuum;
ON CONFLICT DO SELECT— upsert, возвращающий уже существующие строки;IGNORE NULLSв оконных функциях;- улучшения логической репликации.
Под вопросом, но пока живы: быстрый путь проверки внешних ключей, REPACK/REPACK CONCURRENTLY и импорт статистики в postgres_fdw.
Про мой предыдущий пост
В разборе новых системных вьюх PostgreSQL 19 я описывал pg_stat_lock, pg_stat_recovery, pg_stat_autovacuum_scores и pg_dsm_registry_allocations.
Ни одна из них в список названных откатов не попала, а связанный с третьей переход autovacuum на приоритизацию по баллам — среди того, что остаётся. Но названо только одиннадцать откатов из пятидесяти трёх, и бета продолжается. Сверяйтесь с финальными release notes, а не с текстами, написанными до релиза, — включая мой.
Почему это хорошая новость
Три причины смотреть на ситуацию спокойно.
Откатывать во время беты — признак работающего процесса. Альтернатива выглядит так: сомнительная фича выходит в релиз, попадает в дистрибутивы, а потом живёт с нами годы, потому что выкинуть её из мажорной версии уже нельзя. PostgreSQL выбрал выкинуть сейчас.
Часть откатов — про инфраструктуру, а не про код. lz4 по умолчанию отложили не потому, что он плох, а потому что не вся сборочная инфраструктура его поддерживает. Это осторожность, а не провал.
Баги искали агрессивно. Роберт Хаас устраивал «конкурс страшных багов» с тест-кейсами, сгенерированными ИИ. Отдельно любопытно, как это меняет саму экономику тестирования: генерировать экзотические комбинации запросов машина умеет лучше человека, а именно на них и ломаются оптимизации вроде GROUP BY ALL.
Что делать практически
- Не назначайте миграции на предполагаемые даты. Если в вашем плане на квартал стоит «переезд на 19-ю», переносите ориентир и закладывайте запас.
- Проверьте, не ждали ли вы конкретно откаченного. Особенно это касается тех, кто рассчитывал на
SQL/PGQили на онлайновые контрольные суммы: их не будет, планируйте без них. - Следите за списком открытых вопросов в вики PostgreSQL — там состояние актуальнее любых статей.
- Не спешите и после релиза. Обычная практика для мажорных версий — подождать первых минорных обновлений, и в этот раз, с учётом объёма правок в бете, она особенно уместна.
Задержка релиза раздражает, когда вы ждали конкретную возможность. Но база данных — то место, где «вышло вовремя» стоит гораздо меньше, чем «не врёт в ответах».