Релиз-команда PostgreSQL объявила новый график выпуска версии 19: первый кандидат на релиз (RC1) выйдет 15 октября, второй (RC2) — 12 ноября, а финальная сборка — 19 ноября. Ранее выпуск ожидали в конце сентября или начале октября. До переноса из версии убрали от восьми до десяти крупных функций, а официальной причиной задержки в письме релиз-команды назван большой объём исправлений. О связи переноса с проверкой кода при помощи больших языковых моделей рассказал один из ведущих коммиттеров проекта Питер Эйзентраут, представляющий компанию EDB, — он изложил эту версию в личном блоге 9 октября, подчеркнув, что высказывает собственное мнение, а не позицию сообщества.

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

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

В результате из PostgreSQL 19 в версию 20 перенесли несколько заметных возможностей. Среди них SQL/PGQ — механизм запросов к графам свойств, предусмотренный стандартом SQL; конструкция GROUP BY ALL, отложенная из-за ошибки, при которой запрос мог вернуть неверный результат; а также операции слияния и разделения партиций (MERGE PARTITION и SPLIT PARTITION). При этом в релизе сохраняются REPACK CONCURRENTLY, логическая репликация последовательностей и расширение pg_plan_advice. Контекст здесь важен: PostgreSQL развивается по строгому циклу с бета-версиями и релиз-кандидатами, и любое изменение сроков внутри такого цикла обычно означает, что сообщество предпочло стабильность соблюдению календаря. Для проекта с репутацией одной из самых надёжных СУБД это ожидаемая логика, хотя она и отодвигает появление долгожданных функций на следующий крупный релиз.

Для российского рынка ситуация имеет прикладное значение, поскольку PostgreSQL остаётся базовой платформой для значительной части корпоративных и государственных систем, а также основой для ряда отечественных форков и дистрибутивов. Перенос крупных функций на версию 20 означает, что компании, планировавшие миграцию ради SQL/PGQ или работы с партициями, будут вынуждены скорректировать дорожные карты. Одновременно кейс демонстрирует, как LLM встраиваются в процессы разработки критической инфраструктуры: не как замена инженеров, а как инструмент аудита, повышающий плотность находимых дефектов. Отраслевые наблюдатели, включая Snowflake, которая отслеживает цикл выпуска, пока рекомендуют обновляться до PostgreSQL 18 — более предсказуемой и уже проверенной ветки.

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

Дальнейшее развитие событий будет зависеть от того, как сообщество встроит LLM-проверки в процесс: если они станут регулярными и будут применяться на ранних стадиях, поток отчётов распределится по циклу разработки и перестанет давить на финальную стадию беты. Открытым остаётся вопрос, последуют ли другие крупные open-source проекты примеру и начнут ли публиковать статистику по дефектам, найденным моделями, — пока таких данных нет ни у PostgreSQL, ни у большинства смежных инициатив. Ближайшие контрольные точки — RC1 15 октября, RC2 12 ноября и финальный выпуск 19 ноября — покажут, удастся ли уложиться в обновлённый график и не потребуется ли ещё один перенос.