Перенос PostgreSQL 19: как LLM-ревью изменило цикл разработки
Финальный релиз базы данных PostgreSQL 17 перенесен с конца сентября на 19 ноября. Релиз-команда объясняет решение необходимостью доработки накопившихся исправлений, однако сообщество связывает задержку с внедрением инструментов искусственного интеллекта для проверки кода.
# PostgreSQL 19 отложен: влияние ИИ на качество кода
Релиз-команда проекта PostgreSQL официально объявила о переносе финальной версии (GA) 19-го выпуска на 19 ноября. Изначально релиз планировался на конец сентября или начало октября. В промежуточных версиях — Release Candidate 1 (15 октября) и новой Release Candidate 2 (12 ноября) — откатили от восьми до десяти заметных функций. Хроника событий и детали причин описаны ниже.
Официальная позиция vs. интерпретация сообщества
В письме от 10 октября, адресованном списку pgsql-hackers, Джонатан Кац, выступающий от имени релиз-команды, подчеркнул, что задержка вызвана объемом исправлений, накопившихся в ветках поддержки. Целью было прогнать критические правки перед финалом, чтобы обеспечить стабильность продукта.
*«Мы понимаем, что этот цикл мажорного релиза получился нетипичным, но хотим и дальше выпускать стабильный и надежный PostgreSQL»*, — написал Кац. В официальном документе слово «искусственный интеллект» не фигурировало.
Связь с машинным обучением стала очевидной позже. Питер Эйзентраут, ведущий коммиттер проекта и сотрудник EDB, в своем блоге объяснил ситуацию как следствие повышения планки качества проверки кода с помощью LLM (Large Language Models). Инструменты быстро выявляют «длинный хвост» граничных ошибок, которые в прошлые циклы решались годами, но теперь требуют немедленного исправления перед релизом.
Цифры, которые разнятся: от 40 багов до 53 откатов
В медиапространстве возникли размытые цифровые метрики, которые часто путают. Утверждение о «сорока отчетах о дефектах» приводится как иллюстрация проблемы, описанная Эйзентраутом: *
*«...и вот вы смотрите на список примерно из сорока отчетов о дефектах»*. Он поясняет, что исправление каждого пункта требует написания кода, тестов и ревью, а при наличии десятков таких задач на финальной стадии бета-тестирования времени не остается.
Отдельные цифры, такие как 8–10 функций и 53 отката, также требуют контекста. Snowflake насчитала 53 отката с начала бета-тестирования PostgreSQL 19, в то время как в цикле PostgreSQL 18 было около 44. Однако методики подсчета разнятся: автор Snowflake не уточняет, считает ли она все коммиты или только значимые изменения. В PostgreSQL 19 многие откаты произошли поздно, что и стало поводом для дискуссий об эффективности LLM-ревью.
Что было откатано и где оно переместится
Из ветки PostgreSQL 19 было извлечено несколько важных функций, включая SQL/PGQ (частичный стандарт SQL) и операции GROUP BY ALL (отмеченные как опасные из-за риска неверных результатов без явной ошибки запроса).
Самая заметная потеря для разработчиков — SQL/PGQ, функция, которая стала стандартом с 2023 года. Том Лейн предупреждал, что ее запуск мог привести к появлению багов, исправление которых отложится до PostgreSQL 20. Также в списки откатов попали:
* Запросы к графам свойств. * Операции ALTER TABLE MERGE/SPLIT PARTITION(S). * Смена сжатия TOAST на lz4 по умолчанию. * Вложенный трекинг запросов в pg_stat_statements. * Онлайн-включение контрольных сумм данных.
Эти функции переместились в roadmap PostgreSQL 20, который теперь ожидается как выпуск с исправлениями. Тем временем, PostgreSQL 19 сохранит ряд полезных нововведений, таких как REPACK CONCURRENTLY, логическая репликация последовательностей и улучшения оконных функций.
Почему именно этот цикл пострадал
Согласно анализу Эйзентраута, на ситуацию повлияли несколько факторов, и LLM-ревью стало катализатором, а не единственной причиной:
1. Новые стандарты качества: Многие функции были написаны давно, когда автоматизированное ревью не работало так эффективно. Новые инструменты сразу выявили ошибки, которые ранее проходили бы. 2. Эффект «Vulnpocalypse»: С апреля по август основные силы сообщества были заняти устранением уязвимостей безопасности (CVE), что сократило ресурсы на тестирование. 3. Комбинаторика взаимодействий: PostgreSQL сложна в тестах из-за тысяч комбинаций доменов, триггеров и партиций. LLM-фаззинг помогает находить ошибки в редких сочетаниях, которые человек не перепроверит вручную.
Отмечается, что код откатанных функций был написан задолго до внедрения подобных систем, а официальная политика PostgreSQL по использованию ИИ в разработке пока не сформирована. Ожидается, что такой подход станет штатной частью процесса в ближайшее время.
Что ждать до 19 ноября
Релиз без откатанных функций все равно будет содержательным. Команда рекомендует отслеживать изменения в RC2 от 12 ноября и проверять закрытые задачи в репозитории перед финальным выпуском. Если гипотеза об эффективности LLM верна, минорные обновления PostgreSQL 19 должны быть стабильнее, чем предыдущие мажорные версии. Особое внимание стоит уделить отсутствию SQL/PGQ и GROUP BY ALL в финальном составе.
Остается вопрос открытым: как сообществу реагировать на функции, где ИИ-ревью обнаруживает десятки проблем за месяц до релиза? Откат или выпуск с известными ограничениями — дилемма, с которой столкнутся разработчики в будущих версиях.