Коммиттер PostgreSQL: LLM-ревью нашло в версии 19 больше ошибок, чем успели исправить
Релиз-команда PostgreSQL перенесла финальную версию PostgreSQL 19 на 19 ноября. До этого из ветки откатили от восьми до десяти заметных функций, и The Register связал происходящее с ревью кода через LLM. Ниже разобрано, что сказано в официальном объявлении, как ситуацию объясняет один из ведущих коммиттеров проекта и где цифры из пересказов разошлись с первоисточниками.
TL;DR
GA PostgreSQL 19 перенесён на 19 ноября. RC1 оставили на 15 октября, добавили RC2 на 12 ноября. Изначально релиз ждали в конце сентября или начале октября.
Официальная причина в письме релиз-команды — объём исправлений в ветках поддержки. Про ИИ и откаты функций в объявлении ни слова.
Связь с LLM-ревью проводит Питер Эйзентраут (EDB, коммиттер PostgreSQL). Инструменты быстро вытаскивают длинный хвост граничных ошибок, а на каждое исправление нужно время.
«Около 40 отчётов о дефектах», которые гуляют по пересказам, — образ из рассуждения Эйзентраута. Реального подсчёта найденных багов никто не публиковал.
«8–10 значимых функций» и «53 отката» от Snowflake измеряют разное. Вторая цифра считает все откаты с начала беты, в PostgreSQL 18 их было около 44.
SQL/PGQ, GROUP BY ALL, слияние и разделение партиций переезжают в PostgreSQL 20.
Snowflake сейчас называет безопасной целью для обновления PostgreSQL 18.
Что объявила релиз-команда PostgreSQL 10 октября
Письмо в рассылку pgsql-hackers отправил Джонатан Кац от имени релиз-команды. График выглядит так:
RC1 — 15 октября, без изменений;
RC2 — 12 ноября, в один день с плановым выпуском минорных обновлений;
GA — 19 ноября, через неделю после них.
RC2 понадобился, чтобы до финала прогнать исправления, накопившиеся в ветках поддержки. Отдельно Кац признаёт, что цикл вышел необычным:
«Мы понимаем, что этот цикл мажорного релиза получился нетипичным, но хотим и дальше выпускать стабильный и надёжный PostgreSQL, и принимали решения исходя из этой цели», — написал Джонатан Кац.
LLM в письме не упоминаются. Тезис «ИИ сдвинул релиз PostgreSQL» — интерпретация The Register, построенная на блоге Эйзентраута. Она правдоподобна, но формально перенос GA объяснён объёмом исправлений, а не ревью.
Откуда в пересказах взялись «сорок отчётов о дефектах»
Цифра 40 кочует по агрегаторам как число багов, найденных LLM в PostgreSQL 19. В первоисточнике это иллюстрация. 9 октября Эйзентраут опубликовал пост с названием «The reverts will continue until morale improves» и описал типичную ситуацию с функцией, которую прогнали через LLM-ревью:
«…и вот вы смотрите на список примерно из сорока отчётов о дефектах», — описал ситуацию Питер Эйзентраут.
Дальше он поясняет, что исправление каждого пункта может занимать пару строк кода, но у каждого есть фиксированная цена. Нужно разобраться, написать тест, получить ревью, закоммитить. Когда таких пунктов десятки, а бета подходит к концу, времени не хватает. Ни Эйзентраут, ни The Register, ни релиз-команда PostgreSQL общего числа найденных дефектов не называют.
53 отката и 8–10 функций — два разных счёта
Обе цифры звучат рядом, но измеряют разное.
Эйзентраут пишет про «примерно 8–10 значимых функций, в зависимости от того, как считать». Обычно в цикле PostgreSQL откатывают примерно одну такую функцию, так что разница на порядок.
Snowflake в материале от 16 сентября насчитала 53 отката с начала бета-тестирования PostgreSQL 19 против примерно 44 у PostgreSQL 18. Методику автор, Элизабет Гаррет Кристенсен, не раскрывает. Скорее всего, речь о revert-коммитах, а один откат функции может растянуться на несколько коммитов. Сравнение 53 и 44 само по себе драматичным не выглядит. Snowflake подчёркивает другое. В PostgreSQL 18 откаты в основном пришлись на первые недели беты, в PostgreSQL 19 многие случились поздно и, по формулировке Snowflake, после «глубоких ревью, сгенерированных ИИ».
Что откатили из PostgreSQL 19
Snowflake на 16 сентября перечисляет такие откаты:
SQL/PGQ, запросы к графам свойств;
ALTER TABLE MERGE/SPLIT PARTITION(S);
UPDATE/DELETE FOR PORTION OF;
GROUP BY ALL — из-за ошибки с ORDER BY, которая давала неверные результаты;
смена сжатия TOAST по умолчанию на lz4;
нетекстовые форматы вывода pg_dumpall;
каскадирование ON ERROR в JSON_TABLE;
быстрые значения по умолчанию для доменов с неволатильными ограничениями;
снимки логической репликации для отдельных баз;
вложенный трекинг запросов в pg_stat_statements;
онлайн-включение контрольных сумм данных.
Самая заметная потеря — SQL/PGQ, часть стандарта SQL с 2023 года. По данным The Register, Том Лейн предупреждал, что после выхода PostgreSQL 19 в этой функции всплывут баги, которые нельзя будет исправить до PostgreSQL 20. Случай с GROUP BY ALL показательнее для темы ревью. Неверный результат запроса без ошибки и предупреждения — тот класс дефектов, который в релизе обходится дороже всего.
Почему LLM-ревью ударило именно по этому циклу
Эйзентраут сам был автором или коммиттером части откатанных функций и прямо оговаривает, что излагает личное мнение. Его объяснение многофакторное, и LLM там только одна из причин:
Старый код под новой планкой. Многие функции написаны давно, когда LLM-ревью было заметно слабее. Инструменты подняли фактическую планку качества посреди цикла, и код, который раньше прошёл бы, перестал её проходить.
Хвост граничных случаев. Раньше такие ошибки находили годами и чинили в минорных релизах. LLM-ревью вытаскивает их сразу и пачкой.
«Vulnpocalypse». С апреля по август ключевые разработчики PostgreSQL были заняты исправлением уязвимостей, и на ревью и тестирование беты осталось меньше сил. Snowflake приводит масштаб: раньше на релиз приходилась пара CVE, августовский патч PostgreSQL 18 закрыл 28.
Комбинаторика. В PostgreSQL почти всё сочетается со всем — домены, партиции, представления, триггеры. Вручную такие сочетания не перебрать, и Эйзентраут предлагает делать LLM-фаззинг частью разработки функций.
Вайб-кодинг ни при чём. Код откатанных функций написан задолго до того, как такой подход стал возможен.
Есть и организационная сторона. В сообществе обсуждают возможность коммитить функции со статусом «экспериментальная» и дорабатывать их в основном дереве, но рабочего механизма пока нет. Официальной политики PostgreSQL по вкладу с помощью ИИ тоже нет, Snowflake пишет, что её ждут в ближайшее время.
Что остаётся в PostgreSQL 19 и что ждёт PostgreSQL 20
Релиз без SQL/PGQ всё равно содержательный. Эйзентраут и Snowflake называют:
REPACK CONCURRENTLY — освобождение места без блокировки таблицы, в отличие от VACUUM FULL;
логическую репликацию последовательностей — её тоже откатывали, но вернули;
pg_plan_advice, параллельный autovacuum, ON CONFLICT DO SELECT и IGNORE NULLS в оконных функциях.
Для PostgreSQL 20 картина поменялась. По данным The Register, следующую версию ждали как релиз в основном с исправлениями, теперь в неё переедут откатанные функции. Эйзентраут добавляет, что несколько функций для PostgreSQL 20 уже почти готовы.
Что отслеживать до 19 ноября и после
Главный тезис Эйзентраута проверяем на практике. Если LLM-ревью действительно вытащило граничные ошибки до релиза, первые минорные версии PostgreSQL 19 должны получиться спокойнее, чем у прошлых мажорных релизов. Перед переходом стоит смотреть на несколько вещей:
список изменений RC2 от 12 ноября относительно RC1 — по нему видно, сколько исправлений накопилось за месяц;
открытые пункты PostgreSQL 19 в вики проекта, которые релиз-команда закрывает перед GA;
совпадение планов миграции с итоговым составом релиза — SQL/PGQ, GROUP BY ALL и операции MERGE/SPLIT PARTITION в нём не будет;
минорное обновление PostgreSQL 18 от 12 ноября, если обновление на 19 решено отложить;
появление официальной политики PostgreSQL по ИИ-вкладу — от неё зависит, станет ли LLM-ревью штатной частью процесса.
Как, по-вашему, правильнее поступать с функцией, в которой LLM-ревью за месяц до релиза нашло десятки граничных ошибок, — откатывать её или выпускать с известными ограничениями?
Ссылки по теме
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.