Postgres 19 сдвигается на ноябрь: LLM-ревью нашло слишком много багов, чтобы успеть

Планка выросла после того, как код уже написан

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

Самая заметная жертва — SQL/PGQ, функция запросов к графам свойств на SQL. Том Лейн предупреждал, что поставка её в 19-й версии породит баги, которые нельзя будет исправить до 20-й. REPACK CONCURRENTLY остаётся в релизе, а Эйзентраут назвал 19-ю версию «отличным релизом», который будет «очень надёжным».

Тестировщики Postgres говорят, что пробелы были и раньше

Самый информативный голос принадлежит соавтору pgrust, переписанной на Rust версии Postgres, который раньше руководил Freshpaint и возглавлял команду баз данных в Heap, потому что он сам охотится за такими багами со стороны проекта:

«Если бы мне нужно было назвать первопричину, почему мы находим сейчас так много багов, я бы объяснил это ограниченностью тестового набора Postgres. ИИ просто вскрывает баги, которые уже существовали.»

Он говорит, что нашёл около 50 багов в ядре Postgres. Делал он это не через просьбу к модели проверить код, а с её помощью строил детерминированное симуляционное тестирование, дифференциальный фаззинг и формальные доказательства. Скептики пошли в другую сторону. Инженер, который этим летом натравил друг на друга агента-ревьюера и агента-кодера, попал в цикл: «ревьюер находил баги, кодер исправлял их каким-то переусложнённым способом, добавляя новые баги… и так до безумия. Не каждый раз. Но достаточно часто.»

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