Релиз PostgreSQL 19 перенесли на 19 ноября: ревью с помощью LLM вскрыло десятки скрытых багов

В чём суть?

Десятого октября релиз-команда PostgreSQL объявила новый график выхода девятнадцатой версии: RC1 пятнадцатого октября, RC2 двенадцатого ноября, финальный релиз девятнадцатого ноября. Раньше релиз ждали в конце сентября или начале октября. В официальном письме причиной называют большой объём исправлений. Про языковые модели в письме нет ни слова.

Связь с LLM (large language model, большая языковая модель) описал девятого октября Питер Эйзентраут, один из ведущих коммиттеров проекта из компании EDB, в личном блоге. Он подчеркнул, что это его личное мнение, а не позиция проекта.

До переноса из версии убрали от восьми до десяти крупных функций, которые перенесли в PostgreSQL 20. Среди них:

• SQL/PGQ (запросы к графам свойств из стандарта SQL).
• GROUP BY ALL, убрали из-за ошибки, при которой запрос возвращал неверный результат.
• MERGE/SPLIT PARTITION (слияние и разделение партиций, то есть частей таблицы, разбитой на куски для ускорения работы).

В релизе остаются REPACK CONCURRENTLY, логическая репликация последовательностей и pg_plan_advice. Компания Snowflake, которая следит за циклом PostgreSQL, пока советует обновляться на PostgreSQL 18.

LLM нашли то, что люди пропускали годами?

По словам Эйзентраута, многие функции PostgreSQL 19 написали задолго до текущего цикла. Когда код прогнали через LLM-ревью (проверку с помощью языковой модели), оно быстро выявило множество мелких ошибок в редких сочетаниях условий. Раньше такие баги находили годами и закрывали в обновлениях уже после релиза.

«…и вот вы смотрите на список примерно из сорока отчётов о дефектах» : Питер Эйзентраут, коммиттер PostgreSQL, EDB

Число сорок здесь, по словам Эйзентраута, пример типичной ситуации для одной функции. Общее количество найденных ошибок никто не публиковал.

Каждое исправление требует времени на тест и ревью живыми людьми, а бета подходила к концу. Когда дефектов накопилось слишком много, несколько функций решили отложить.

Эйзентраут называет и вторую причину: с апреля по август ключевые разработчики исправляли уязвимости, и на проверку бета-версии осталось меньше рук. К вайб-кодингу (когда код пишут прямо из промпта, без ручного контроля) проблемы отношения не имеют: код писали до того, как этот подход стал популярен.

Аргументы за: LLM-ревью повышает планку качества

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

Второй аргумент: задержка релиза дешевле, чем серия экстренных патчей после выпуска. Отложить функцию с известным багом честнее, чем выпустить её «как есть» и чинить на ходу.

Третий: LLM-ревью не заменяет людей, а расширяет поиск. Модель проверяет те самые редкие комбинации условий, до которых у живого ревьюера не дошли бы руки. Это делает процесс ревью полнее, а не проще.

Аргументы против: модели создают узкое горлышко, а не снимают его

Главная претензия: LLM генерирует массу отчётов, но каждый из них всё равно разбирает человек. Если людей не хватало на обычное ревью, лавина машинных отчётов ситуацию не улучшает, а ухудшает: бета-период заканчивается, а очередь дефектов растёт быстрее, чем команда успевает их закрывать.

Второе возражение: галлюцинации (когда модель уверенно выдумывает то, чего не было) никто не отменял. Если часть отчётов окажется ложными срабатываниями, команда потратит время на проверку несуществующих багов. Эйзентраут в блоге не уточняет долю ложных срабатываний.

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

Что делать российским разработчикам прямо сейчас?

Тем, кто планировал миграцию на PostgreSQL 19 осенью. Пересмотрите сроки: финальный релиз не раньше 19 ноября, а стабилизация в продакшене займёт ещё время. Snowflake пока рекомендует оставаться на PostgreSQL 18.

Тем, кто уже использовал SQL/PGQ или GROUP BY ALL в тестовых ветках. Эти функции перенесены в PostgreSQL 20. Заложите альтернативный путь: для графовых запросов посмотрите расширение Apache AGE, для GROUP BY ALL пишите группировку явно.

Тем, кто задумывается об LLM-ревью собственного кода. Кейс PostgreSQL показывает, что модель находит баги, но каждый отчёт всё равно требует ручной проверки. Без достаточного числа людей на разборе результатов LLM-ревью создаёт пробку, а не ускорение.

Следующий маркер: RC2 двенадцатого ноября. Если и он сдвинется, значит, LLM-ревью нашло больше, чем команда готова переварить за один цикл, и проекту придётся менять не инструмент, а сам процесс выпуска. Для тех, кто строит на PostgreSQL в России, практический вывод проще: держите миграцию на паузе до стабильного 19.0 и заранее уберите из кода зависимости от функций, которые уехали в двадцатую версию.