Postgres 19 задерживается, и виноваты в этом LLM
Postgres 19 is late, and it's AI's fault
Релиз PostgreSQL 19, обычно выходящий в сентябре-октябре, сдвигается на ноябрь. Причина — резкий рост числа найденных ошибок: LLM массово находят баги, которые люди годами не замечали. Число бэкпортированных коммитов выросло на 60–74%, а крупные фичи вроде SQL/PGQ пришлось откатить поздно в бете. Разработчики тратят время на исправления, а не на ревью, и это ставит перед проектом вопрос: как догонять сорок лет невидимых человеку ошибок и при этом развиваться.
LLM заставят каждого разработчика PostgreSQL — и в какой-то степени каждого программиста на Земле — поднять свой уровень.
- CharlesW
> Этот год будет другим. PostgreSQL 19, скорее всего, выйдет не раньше ноября… […] Так что же случилось? Короткий ответ: случились LLM. […] Там огромное количество кода, и этот код содержит огромное количество багов. […] Что изменилось сейчас, так это то, что находить эти баги стало значительно проще.
Похоже, это… хорошо?
То, что это может немного нарушить «традиционный» график релизов проекта, не кажется чем-то ужасным на фоне альтернативы — выпустить ещё одно крупное обновление с багами, которые, судя по всему, давно преследуют кодовую базу.
- tibbar
Этим летом, в перерыве между работами, я немного позанимался поиском багов в Postgres с помощью ИИ, и улов был ошеломляющим. Множественные аномалии сериализации (например, [0] [1] [2]), проблемы целостности внешних ключей ([3] [4]), баги корректности планировщика, такие как [5]. Различные уязвимости, достойные CVE. Неисправимый баг с часовыми поясами [6]. Список стал настолько длинным, что мне пришлось отбирать, что у меня вообще есть время сообщить, и я остановился на дюжине-другой из сотен кандидатов. А теперь представьте, что этим занимается весь мир.
[0] Write skew, наблюдаемый при сериализуемой изоляции:
https://www.postgresql.org/message-id/flat/CA+COZaBo+ZpKgMvx...
[1] Аномалия сериализации: дублирующиеся первичные ключи:
https://www.postgresql.org/message-id/flat/CA+COZaBOiiRPmEfX...
[2] SERIALIZABLE может зафиксировать write skew после суммаризации SSI:
https://www.postgresql.org/message-id/flat/CA+COZaCtK=UQbeQw...
[3] Исправление валидации временных внешних ключей для уже существующих строк
https://www.postgresql.org/message-id/flat/CA+COZaChq_ukm2o7...
[4] Потеря блокировки во время toasting позволяет нарушить FK
https://www.postgresql.org/message-id/flat/CA+COZaC-2-GQabq+...
[5] Отсечение партиций может ошибочно исключить RANGE-партицию по умолчанию
https://www.postgresql.org/message-id/flat/CA+COZaDXrfTaBjLE...
[6] Сравнения timestamp и timestamptz непоследовательно упорядочены при переходе на летнее время: https://www.postgresql.org/message-id/flat/c22286ad6268347c6...
- dabinat
Если в таком зрелом и широко используемом ПО, как Postgres, есть такой уровень скрытых багов, то что тогда говорить о среднем программном продукте?
- hopa
Мне кажется, ИИ потрясающе подходит для «поисковых» задач только для чтения (запросить это, поискать баги, найти уязвимости), но он не так хорош для «писательских» задач вроде «добавь эту фичу». Поисковые задачи легко проверить, изменения кода проверить гораздо сложнее.
- alexpadula
Логично. Кодовой базе больше 30 лет. Над её формированием потрудилось множество рук. Баги будут, так как ни один контрибьютор не держит всю кодовую базу в голове. Именно тестирование должно отлавливать баги. А не чьи-то знания. Я вообще думаю, что будет ещё больше багов, возникающих из ниоткуда, — найденных либо людьми, либо автоматизацией.