LLM‑ревью в PostgreSQL 19: почему перенос релиза не сводится к AI.

Разработчики PostgreSQL перенесли ожидаемый выход версии 19 с конца сентября — начала октября примерно на 19 ноября и исключили из неё от восьми до десяти крупных функций. Событие значимо не только изменением календаря: оно показывает, как LLM‑инструменты способны сдвинуть момент обнаружения дефектов в зрелом проекте, но не отменяют человеческую проверку и ограничения команды по времени.

В официальном объяснении переноса говорится о большом объёме исправлений. Связь с LLM‑ревью отдельно описал ведущий коммиттер PostgreSQL и сотрудник EDB Питер Эйзентраут, причём как личную интерпретацию ситуации, следует из публикации о его комментариях. Поэтому неверно представлять перенос как прямое решение, принятое моделью: LLM стали одним из факторов в более широком процессе ревью и стабилизации ветки.

Что именно изменило LLM‑ревью.

По версии Эйзентраута, часть затронутых возможностей была написана и принята в кодовую базу до того, как LLM‑помощники стали достаточно полезны для такого ревью. Позднее они начали быстрее выявлять редкие сочетания условий и пограничные случаи. Одновременно некоторые функции имели архитектурные недостатки, которые рискованно исправлять в последние недели бета‑цикла. О сочетании этих двух типов проблем — фундаментальных и мелких — сообщает разбор The Register.

Фраза о «примерно сорока отчётах о дефектах» не является опубликованным итоговым числом ошибок PostgreSQL 19. Эйзентраут описывал типичную ситуацию, когда перед командой появляется длинный список находок. Это различие существенно: из приведённой фактуры нельзя вывести ни общее количество дефектов, ни точность LLM‑ревью, ни долю ложных срабатываний. Нельзя и сравнить эффективность конкретных моделей, поскольку инструмент, методика запросов и результаты валидации публично не раскрыты.

Какие возможности перенесли.

Среди перенесённых в PostgreSQL 20 функций названы SQL/PGQ для запросов к графам свойств, GROUP BY ALL и операции слияния и разделения партиций. Для GROUP BY ALL причиной стала ошибка, при которой запрос мог возвращать неверный результат. В пересказе материалов о судьбе SQL/PGQ говорится, что у этой возможности оставались нерешённые проблемы, а не только отдельные косметические дефекты.

Перенос не означает, что релиз лишился всех заметных изменений. В PostgreSQL 19 остаются REPACK CONCURRENTLY, логическая репликация последовательностей и pg_plan_advice. Для пользователей это означает, что оценивать обновление стоит по нужным возможностям, а не по числу исключённых пунктов. Если Ваши планы зависят от графовых запросов или новых операций с партициями, их следует привязывать уже к циклу PostgreSQL 20, а не к текущему релизу.

Почему причинная связь с AI остаётся спорной.

Формула «AI нашёл больше ошибок, чем люди успели исправить» описывает нагрузку на релизный процесс, но не доказывает происхождение всех проблем. Другой коммиттер, Томаш Вондра, изучил обсуждения, связанные с 12 откатами функций, и отнёс только четыре случая к категориям «вероятно AI» или «AI». Этот разбор, приведённый в анализе DEV Community, не опровергает полезность LLM‑ревью, но показывает: отказы от функций нельзя приписывать ему без оговорок.

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

Узким местом остаётся проверка находок.

История PostgreSQL 19 иллюстрирует эффект пропускной способности: ускорение поиска кандидатов на дефект может увеличить очередь на ручную проверку, обсуждение исправления, тестирование и повторное ревью. Даже небольшой патч требует решения, действительно ли сообщение воспроизводимо и не создаёт ли он регрессию. Дополнительным ограничением стало то, что с апреля по август ключевые разработчики занимались исправлением уязвимостей, из‑за чего на бета‑проверку осталось меньше времени.

Релизная команда предпочла убрать спорные или неготовые возможности, а не завершать их под дедлайн. По данным сводки о новом графике выпуска, очередное обновление поддерживаемых версий и второй релиз‑кандидат PostgreSQL 19 ожидаются в один день, при этом в обновление планировали включить большое число исправлений. Это подтверждает, что перенос связан не с единичной находкой, а с накопившимся объёмом работы перед общей доступностью.

Главный вывод для команд, внедряющих LLM в разработку, состоит в разделении поиска и подтверждения дефектов. Модель может быстро расширить список гипотез, но ценность такого списка зависит от точности триажа и возможностей инженеров его обработать. В случае PostgreSQL инструменты ревью, по имеющимся данным, подняли планку качества уже после принятия части кода. Для зрелых проектов это может означать не только больше исправлений, но и необходимость заранее закладывать время на их человеческую верификацию.