Что произошло

Необычно высокое количество функций было откачено из ветки PostgreSQL 19 после начала бета-тестирования. Обычно в цикле разработки отката может быть один-два, но на этот раз откатили от 8 до 10 значительных функций, и некоторые из них — довольно поздно на этапе бета. Разработчикам пришлось столкнуться с этой ситуацией и разобраться, что к чему.

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

  • Недостаточно высокое качество кода. Возможно, код был просто не готов. Это естественная причина, и её стоит назвать прямо, чтобы не создавалось впечатление, что дело только в других факторах. Разработчики будут учиться и улучшаться.

  • Совпадение обстоятельств. Проект шёл так хорошо, что взялись за несколько амбициозных функций, которые оказались слишком сложны для завершения в отведённое время.

  • Архитектурные проблемы и быстрый поиск ошибок. Некоторые откачанные функции имели серьёзные архитектурные дефекты, которые было бы сложно исправить за время бета-тестирования. Но была и длинная цепочка относительно безвредных ошибок на граничных случаях. Раньше такие проблемы обнаруживались намного позже, и их исправляли понемногу в течение пяти лет. Однако с LLM-ассистентами при проверке кода эти проблемы находятся гораздо быстрее — вдруг перед вами список из сорока дефектов. Даже если каждый требует в среднем трёхстрочного исправления, фиксация каждого требует времени, и в итоге временной бюджет исчерпывается. Большинство откачанных функций написаны давно, когда LLM-проверка была не такой эффективной. Иными словами, планка качества поднялась уже после того, как функции были написаны и закоммичены. Если LLM-ассистенты будут улучшаться нынешним темпом, эта проблема должна решиться для следующих циклов разработки.

  • Не "vibe coding". Как минимум, можно сказать, что проблема не в "vibe coding". Этот код писали задолго до того, как такой подход стал возможен.

  • Vulnpocalypse и нехватка внимания. Между апрелем (началом feature freeze для PostgreSQL 19 и началом Vulnpocalypse) и августом (последний релиз безопасности PostgreSQL) старшие разработчики были заняты исправлением проблем безопасности. Из-за этого дополнительная проверка и тестирование, обычно происходящие в бета-период, значительно сократились и возобновились только в августе. Отчасти поэтому много новых проблем обнаружилось довольно поздно, и откаты произошли позже обычного — это сделало ситуацию более заметной. Конечно, были и фундаментальные проблемы, но и много мелких, которые можно было бы решить за два дополнительных месяца и при надлежащем внимании. Однако сообщество предпочло придерживаться графика выпусков, а не откладывать релиз ради дополнительных исправлений. (И никто никогда не знает, насколько на самом деле длинна "длинная цепочка".)

  • Системная сложность и недостаток инструментов. Сложность системы делает некоторые типы функций чрезвычайно трудными в реализации, и в коде недостаточно средств для их поддержки. Возьмём абстрактный пример — некую SQL-уровневую функцию языка запросов. Работает ли она с доменами? А с доменами над составным типом? Где одно из полей тоже домен? И у домена есть ограничение not null? И один из столбцов был удалён и затем добавлен заново? И это часть таблицы-партиции, которая была отделена и переприсоединена с другим порядком столбцов? И это часть представления, вызываемого из security-definer функции внутри триггера? И так далее. Никто не может вручную протестировать все эти случаи или даже их перечислить. Но LLM-assisted fuzzing находит проблемы в таких сценариях очень быстро. Похоже, это должно стать частью разработки функций в будущем. Но также стоит подумать о том, чтобы сделать внутренние интерфейсы более устойчивыми, чтобы каждая комбинация контекстов не открывала столько новых возможностей для взаимодействий.

    В PostgreSQL принято говорить: "всё работает со всем". Это часть привлекательности системы — можно создавать такие комбинации и ожидать, что они будут работать. Никто не хочет отказываться от этого принципа. Но это налагает серьёзную нагрузку на разработку функций, о которой нужно помнить.

  • Экспериментальный статус для функций. PostgreSQL уже давно обсуждает возможность коммитить функции с "экспериментальным" статусом и затем развивать их в основной ветке. Это помогло бы решить предыдущую проблему. Такой инструмент пригодился бы для некоторых откачанных функций, но сообщество ещё не нашло способ это реализовать, и часть работы пострадала от неправильного понимания этой идеи. Это конкретный вопрос для работы.

Что дальше

Прежде всего, огромное спасибо всем, кто выражал поддержку и ободрение. Это самое важное. Уверенность в том, что многие откачанные функции вернутся в ближайшем будущем, есть.

PostgreSQL 19 всё равно будет отличным релизом. REPACK CONCURRENTLY, логическая репликация последовательностей (сама по себе когда-то откачивавшаяся функция) и planner hinting с pg_plan_advice — только несколько из ключевых фич, которые делают этот релиз очень привлекательным. И он будет очень надёжным благодаря дополнительной проверке.

Трудно предсказывать будущее. Несколько месяцев назад казалось, что PostgreSQL 20 может быть релизом только с исправлениями ошибок. Но события развивались ещё быстрее, и PostgreSQL 19 теперь имеет примерно вдвое меньше крупных функций, чем ожидалось тогда. Зато уже накоплены несколько хороших 80%-готовых функций для PostgreSQL 20, которым нужно добавить оставшиеся 20%!