Релиз PostgreSQL 19 перенесли на 19 ноября из-за правок

Подробно

Когда выйдет PostgreSQL 19?

По новому графику PostgreSQL 19 RC2 выйдет 12 ноября 2026 года, а финальный выпуск запланирован на 19 ноября. Предыдущий формальный график проект объявил 28 сентября: RC1 - 15 октября, GA - 29 октября, если не найдут существенных проблем. Значит, относительно последней официально назначенной даты релиз сдвинулся на три недели.

«Команда релиза решила перенести PostgreSQL 19 GA на 19 ноября», - написал Джонатан Кац в рассылке pgsql-hackers.

Дата 19 ноября остаётся плановой. В официальном анонсе RC1 оговорено, что новый серьёзный дефект может потребовать ещё одного релиз-кандидата или очередного переноса.

Почему перенесли PostgreSQL 19?

В сообщении от 10 октября release team называет непосредственной причиной объём исправлений:

«Из-за объёма исправлений, добавленных в поддерживаемые ветки, команда хотела сначала сделать их доступными в PostgreSQL 19 RC2».

Большие языковые модели в официальном сообщении о переносе не упоминаются. О роли ИИ рассказал Петер Айзентраут в личном блоге 9 октября. Он член Core Team PostgreSQL и коммиттер проекта, а в EDB занимает должность VP, Chief Architect, Database Servers. Айзентраут называет сразу несколько сочетавшихся причин откатов: недостаточное качество части кода, случайное совпадение в одном цикле нескольких слишком сложных функций, архитектурные дефекты, множество мелких пограничных ошибок, нехватку времени разработчиков и высокую сложность взаимодействия между возможностями PostgreSQL.

Ещё один фактор, по словам Айзентраута, - уязвимости. С апреля, когда началась заморозка функций PostgreSQL 19, и до августа многие старшие разработчики были заняты исправлением уязвимостей, поэтому привычного объёма тестирования в бета-периоде не было, и активная проверка возобновилась позже. Масштаб этой работы виден по официальному августовскому выпуску PostgreSQL 18.6, 17.11, 16.15, 15.19 и 14.24: он закрыл 28 уязвимостей и более 110 ошибок.

Какие функции удалили из PostgreSQL 19?

В официальном анонсе Beta 4 от 24 сентября перечислены снятые или отменённые изменения:

• SQL/PGQ - синтаксис SQL Property Graph Queries для запросов к связям между вершинами и рёбрами графа;
• включение и отключение контрольных сумм без остановки кластера (online checksums);
• временные UPDATE/DELETE с FOR PORTION OF;
• команды ALTER TABLE MERGE PARTITIONS и SPLIT PARTITIONS;
• функции pg_get_role_ddl(), pg_get_tablespace_ddl() и pg_get_database_ddl();
• изменение, принудительно задававшее LC_COLLATE=C в postmaster.

Ещё раньше из ветки убрали GROUP BY ALL и нетекстовые форматы вывода pg_dumpall. Откат pg_dumpall подтверждён в анонсе Beta 2. Поэтому Айзентраут и даёт диапазон: всё зависит от того, считать ли парные команды и три DDL-функции по отдельности или одним блоком.

«Обычно можно ожидать примерно один откат за цикл, а на этот раз сняли около 8-10 значительных функций, смотря как считать», - пишет Айзентраут.

Об SQL/PGQ опасения высказывали заранее. Коммиттер Том Лейн 25 августа указывал, что вокруг изменений дерева разбора и системного каталога продолжаются обсуждения:

«Если выпустить SQL/PGQ в v19, после релиза, вероятно, обнаружатся ошибки, которые нельзя будет исправить до v20».

Некоторые крупные новинки в версии остались: REPACK CONCURRENTLY, логическая репликация последовательностей и управление планировщиком через pg_plan_advice. Между Beta 4 и RC1 в них, а также в планировщик, логическую репликацию, postgres_fdw, parallel autovacuum и JSON-вывод COPY внесли дополнительные исправления. Вернутся ли снятые функции именно в PostgreSQL 20, не подтверждено: анонс Beta 4 говорит лишь о возможном включении в одну из следующих основных версий, а Айзентраут выражает уверенность, что многие из них вернутся.

Какую роль в задержке сыграли ИИ-рецензенты?

По словам Айзентраута, рецензирование кода с помощью LLM стало гораздо быстрее находить длинный хвост сравнительно безвредных пограничных дефектов. Но каждое такое сообщение всё равно разбирает, тестирует и проверяет человек.

«С LLM-рецензированием такие вещи находятся намного быстрее, и перед вами оказывается список примерно из сорока сообщений о дефектах».

«Даже если каждое исправление в среднем занимает лишь три строки, обработка каждого сообщения имеет постоянные накладные расходы, и времени не хватает».

В то, что дело в vibe coding, Айзентраут не верит:

«По крайней мере в основном эта ситуация возникла не из-за vibe coding: код был написан задолго до того, как это стало возможным».

По его мнению, LLM-рецензирование подняло фактическую планку качества уже после того, как функции написали и приняли.

ИИ применяли и для оценки рисков. 25 августа коммиттер Роберт Хаас открыл в pgsql-hackers обсуждение «scary patch contest». Он попросил Claude ранжировать самые рискованные патчи PostgreSQL 19 по количеству и типам исправлений, сделанных после заморозки функций. В его списке: около 16 исправлений для ускоренной проверки внешних ключей, 28 для REPACK/REPACK CONCURRENTLY, около 25 для online checksums, по 17 для FOR PORTION OF и SQL/PGQ и 7 для импорта статистики в postgres_fdw. Это ранжирование уже сделанных исправлений, а не ошибки, которые Claude нашёл сам. С этого обсуждения началась массовая переоценка функций перед релизом.

28 августа участник разработки Жолт Паррадьи сообщил, что LLM-проверка взаимодействий функций прошла около 30% первого раунда и выдала 22 вопроса или дефекта с воспроизводимыми примерами. Он использовал модель Fable. В блоге Percona Паррадьи пишет, что современные модели уже находят в патче столько же проблем, сколько люди, или больше, но им по-прежнему нужно человеческое руководство:

«При хорошем промптинге главное, чего пока не хватает ИИ, - рецензирование на уровне дизайна».

При этом задержку он связывает не только с ИИ, но и с нагрузкой от исправления уязвимостей.

Правда ли, что ИИ нашёл больше багов, чем люди успели исправить?

Так сформулирован заголовок The Register, но сам текст издания осторожнее: в нём LLM-рецензирование названо лишь одной из причин откатов. LWN описало историю как размышление члена Core Team о необычно большом числе откатов и привело оговорку Айзентраута о vibe coding.

Контролируемого сравнения ИИ с людьми никто не публиковал: неизвестно, сколько дефектов нашли модели и сколько люди, насколько точны модели и как часто они ошибаются. Цифра «около сорока» - пример из личного объяснения Айзентраута, а не сводный подсчёт. Полный список этих сообщений, модели, промпты и доля подтверждённых дефектов не раскрыты. Ранжирование Хааса и проверка Паррадьи - данные самих участников, а не независимые испытания. В начале сентября участник сообщества Джошуа Дрейк предлагал отложить PostgreSQL 19 до весны 2027 года, чтобы функции успели созреть, но проект это предложение не принял.

Можно ли скачать PostgreSQL 19 RC1?

Да. RC1 вышел 15 октября, исходники и пакеты доступны на глобальном сайте PostgreSQL для Linux, macOS, Windows, BSD и других платформ. Региональных ограничений, в том числе для России, проект не объявлял. По оценке проекта, RC1 в основном совпадает с будущим GA-релизом, но в него ещё могут внести исправления. Сборка предназначена для тестирования и оценки, а не для рабочих систем. Чтобы перейти с предыдущей основной версии, нужен pg_upgrade, pg_dump/pg_restore или другой способ обновления основной версии. PostgreSQL распространяется бесплатно по лицензии PostgreSQL License, в том числе для коммерческого использования.