В цикле PostgreSQL 19 из релиза выпало сразу несколько крупных возможностей — по разным оценкам, от восьми до десяти. Разбираем, что именно откатили и почему, как устроен процесс CommitFestпериодический перерыв в разработке PostgreSQL, посвящённый ревью и коммиту патчей, а не новой разработке, в котором такие решения принимаются, и как LLM-ассистированное ревьюпроверка кода с помощью больших языковых моделей меняет баланс между сложностью системы и скоростью разработки.
Что именно откатили и почему
Конкретные откаченные возможности не называются — известно лишь, что было откачено «about 8 to 10 significant features, depending on how you count». Причины делятся на два слоя.
Первый — архитектурный. У части откаченных возможностей были значительные архитектурные дефекты, которые было бы трудно быстро исправить в бете. Сложность системы делает некоторые виды возможностей чрезвычайно трудными для корректной реализации, и в коде не хватает «строительных лесов» для их поддержки.
Второй — длинный хвост относительно безобидных проблем с edge caseредкими сочетаниями условий, в которых поведение системы отклоняется от ожидаемого. Именно такие проблемы стало возможно находить гораздо быстрее благодаря LLM-ассистированному ревью кодапроверке патчей с привлечением больших языковых моделей, которые быстро перебирают комбинации контекстов и находят редкие случаи.
Отдельный фактор — из-за волны проблем безопасности многие старшие разработчики оказались заняты с апреля (начало feature freezeэтапа, на котором прекращается приём новых возможностей и начинается стабилизация релиза для PostgreSQL 19) по август (последний на тот момент релиз безопасности) исправлением security issuesпроблем безопасности. Это сократило обычное дополнительное ревью и тестирование в бета-периодеэтапе публичного тестирования перед выпуском релиза.
Автор считает, что PostgreSQL 19 всё ещё будет отличным релизом и будет очень надёжным после всей дополнительной проверки.
Почему сложность системы — это штраф на разработку
Автор описывает механику так: в PostgreSQL «всё работает со всем». Это часть привлекательности — можно сконструировать почти любую комбинацию контекстов и ожидать, что она заработает. Но это же накладывает значительный штраф на разработку возможностей, о котором все должны знать.
Абстрактный пример — некоторая возможность на уровне SQL-языка запросов. Вопрос не в том, работает ли она сама по себе, а в том, работает ли она во всех комбинациях: с доменамитипами данных, определяемыми пользователем поверх базового типа и способными нести собственные ограничения; с доменами над составным типом; где одно из полей тоже домен; где у домена есть ограничение not null; где один из столбцов был удалён и добавлен заново; где это часть отсоединённой и присоединённой заново секционированной таблицытаблицы, разбитой на секции по определённому правилу с другим порядком столбцов; где это часть представления, вызываемого из security-definer функциифункции, выполняющейся с правами своего владельца, а не вызывающего из триггера.
Никто не может вручную протестировать или даже перечислить эти тестовые случаи. Но LLM-ассистированный фаззингавтоматический поиск сбоев на случайных комбинациях входных данных с привлечением языковых моделей находит проблемы в таких комбинациях очень быстро — и именно поэтому хвост edge cases стал обнаруживаться раньше и плотнее, чем в прошлых циклах.
Как устроен CommitFest
CommitFest (CF) — это периодический перерыв в разработке PostgreSQL, посвящённый ревью и коммиту патчей, а не новой разработке. CF проводятся, чтобы вся работа для релиза получала относительно быструю обратную связь и не накапливалась к концу цикла.
В период CF контрибьюторов просят ревьюить и тестировать патчи, поданные другими. CommitFest Managerкоординатор, который организует ревью всех поданных патчей управляет списком. Патчи регистрируются в приложении CommitFest, которое разработчики используют для отслеживания статуса патча.
В цикле крупного релиза обычно пять CommitFest'ов: июль, сентябрь, ноябрь, январь и март. Мартовский — финальный; после него наступает feature freeze и начинается бета-период.
Участвовать может любой: подать патч, записаться на ревью или стать CommitFest Manager (хотя менеджеры обычно имеют некоторый опыт в сообществе). Патч в итоге либо коммититсявключается в основную ветку кода PostgreSQL, либо возвращается автору с обратной связью, либо отклоняется, если сообщество решит, что изменения бесполезны.
Проект PostgreSQL также участвует в программе Google Summer of Code; для интересующихся работой над связанным с PostgreSQL проектом есть страница Summer of Code, где можно получить информацию о проектах и участии.
Что из этого следует на практике
Откат восьми–десяти значительных возможностей — не признак кризиса процесса, а его работа. Механика здесь такая: длинный хвост edge cases стал находиться быстрее благодаря LLM-ассистированному ревью, а часть дефектов оказалась архитектурной и не поддавалась быстрому исправлению в бете. Параллельно VulnpocalypseПериод, когда многие старшие разработчики PostgreSQL были заняты исправлением проблем безопасности, что сократило обычное дополнительное ревью и тестирование в бета-периоде. оттянул старших разработчиков на security-исправления, сократив дополнительное ревью и тестирование в бета-периоде.
Практический вывод для тех, кто планирует миграцию: релиз, из которого выпало много возможностей, но который прошёл усиленную проверку, стоит оценивать по тому, что в нём осталось. REPACK CONCURRENTLYКоманда PostgreSQL, которая переписывает таблицу без блокировки параллельных операций и остаётся в релизе PostgreSQL 19., логическая репликация последовательностейВозможность PostgreSQL реплицировать значения последовательностей через логическую репликацию, которая остаётся в релизе PostgreSQL 19. и pg_plan_adviceМеханизм подсказок планировщику запросов PostgreSQL, который остаётся в релизе PostgreSQL 19. сохраняются — по словам автора, именно они делают релиз привлекательным.
Для тех, кто сам разрабатывает возможности под PostgreSQL: комбинаторный взрыв контекстов (домены, секционирование, представления, security-definer функции, триггеры) — это не крайние случаи, а нормальная поверхность тестирования. Ручного перебора здесь не хватит, и LLM-ассистированный фаззинг становится частью процесса, а не надстройкой.
