PostgreSQL 19 выйдет 19 ноября. Раньше релиз ждали в конце сентября или начале октября, так что сдвиг получился больше месяца. Новый график релиз-команда объявила 10 октября: RC1 15 октября, RC2 12 ноября, финальный релиз 19 ноября (публикация с деталями).
Официальная причина переноса - большой объём исправлений. Про ИИ в письме релиз-команды ничего нет. Связь части задержки с проверкой кода языковыми моделями описал Питер Эйзентраут, один из ведущих коммиттеров PostgreSQL из EDB, в личном блоге 9 октября, и там же оговорил: это его личное мнение.
Для тех, кто планирует обновление, картина такая: релиз выходит позже и с урезанным набором функций. SQL/PGQ, GROUP BY ALL и слияние с разделением партиций перенесли в PostgreSQL 20. Дальше по порядку: что сдвинулось в графике, откуда взялась версия про LLM-ревью, как это меняет нагрузку на мейнтейнеров и почему до обкатки 19 разумно оставаться на PostgreSQL 18.
PostgreSQL 19: новая дата выхода и что изменилось в графике
Новый график: RC1, RC2 и финальный релиз
Три даты, которые стоит записать: RC1 - 15 октября, RC2 - 12 ноября, финальный релиз - 19 ноября. RC (release candidate) это предрелизная сборка, в которой новые функции уже заморожены: правят только дефекты и регрессии, найденные при тестировании. Между RC1 и RC2 проходит четыре недели, и в этот интервал умещается лишь то, что успели воспроизвести, починить и отревьюить.
График объявили 10 октября, за пять дней до RC1. Сжатость видна по самой последовательности: на подготовку к первой сборке-кандидату почти не осталось времени, а весь запас на стабилизацию уложился в пять недель между двумя RC и финалом.
Насколько сдвинулся релиз относительно ожиданий
Раньше релиз ждали в конце сентября или начале октября. 19 ноября - это сдвиг больше месяца, причём в неудобную сторону: обновление попадает на конец года, когда команды закрывают квартальные планы и редко запускают миграции на проде.
Точных прежних дат никто не публиковал, поэтому корректно говорить именно про окно «конец сентября - начало октября», а не про конкретное число. Для планирования разница в шесть-семь недель означает, что осеннее окно обновления у вас, скорее всего, уже не совпадёт с выходом 19.
Почему релиз перенесли: официальная причина и мнение Питера Эйзентраута
Официальное письмо релиз-команды: только объём исправлений
В официальном сообщении причина одна: накопился большой объём исправлений, и его нужно довести до релизного качества (разбор ситуации). Про ИИ там ничего нет. Деталь важная: релиз-команда не подтверждала, что задержку вызвала проверка кода языковыми моделями, и любые утверждения такого рода пока остаются на уровне частного мнения.
Что именно написал Эйзентраут и почему это лишь версия
Питер Эйзентраут, один из ведущих коммиттеров PostgreSQL и сотрудник EDB, 9 октября в личном блоге описал механику, которая, по его наблюдению, добавила работы к концу цикла. Многие функции версии 19 написали давно. LLM-ревью быстро находит в них мелкие ошибки в редких сочетаниях условий, тех самых, что годами не всплывали в проде и оседали в списках известных дефектов до очередного обновления.
Каждая находка запускает цепочку: воспроизвести, написать патч, протестировать, отревьюить, включить в релиз. Всё упирается в человеческое время, а бета подходила к концу. «…и вот вы смотрите на список примерно из сорока отчётов о дефектах», так Эйзентраут описал типичную ситуацию. Число 40 в этой фразе приводится как пример масштаба, а не как статистика: общее количество найденных ошибок никто не публиковал.
Подчеркнуть стоит ещё раз: это личный блог, а не официальная позиция проекта. Читать его как «PostgreSQL 19 задержали из-за ИИ» некорректно. Корректная формулировка такая: один из коммиттеров видит в LLM-ревью дополнительный фактор нагрузки на фоне общего объёма исправлений.
Уязвимости апреля-августа и сжатая бета
Вторая причина из того же объяснения с ИИ не связана: с апреля по август ключевые разработчики исправляли уязвимости, поэтому на проверку беты осталось меньше времени, чем планировали. Сложите это с потоком мелких дефектов в конце цикла, и получите задержку без единственной причины. Перенос даты стал результатом наложения факторов: сокращённое окно тестирования плюс больше исправлений, чем успевали обрабатывать.
Как LLM-ревью кода меняет нагрузку на мейнтейнеров
Почему старый код даёт много находок
Редкие ветки условий плохо покрыты тестами, потому что до них трудно добраться. Функция работает годами, сотни комбинаций параметров проверены практикой, а ветка с тремя взаимоисключающими условиями не выполняется почти никогда. Человек-ревьюер такие места просматривает по диагонали: его внимание упирается в diff, а не в археологию кода. Языковая модель перебирает варианты методично и без устали, поэтому находит то, что десять лет лежало мимо тестов.
Отсюда неприятный для планирования эффект: чем старше и стабильнее код, тем больше находок он может дать при первом проходе LLM-ревью. Код, который считался самым надёжным, внезапно приносит десятки отчётов, и каждый требует решения.
Узкое место - тест и ревью, а не поиск
Поиск дефектов перестал быть узким местом. Узким местом стал человек. Цепочка обработки одной находки выглядит так:
- отчёт о дефекте с описанием условий срабатывания;
- воспроизведение на своей сборке, иногда сценарий не воспроизводится, и это отдельное расследование;
- патч, который не должен ломать соседнее поведение;
- тест, фиксирующий исправление;
- ревью другим коммиттером;
- включение в ветку и проверка, что не появилось регрессий.
Шаги со второго по пятый автоматизируются плохо: у каждого свой контекст, свои последствия для совместимости и свои сроки. Плюс любая автоматическая проверка даёт шум: часть отчётов окажется ложной или неприменимой к реальным сценариям, и её тоже надо разобрать, чтобы не тащить в релиз лишние правки. LLM в этой схеме работает как очень быстрый аудитор: он приносит список замечаний, а решения и правки остаются за людьми.
Это не критика LLM-ревью. Инструмент делает ровно то, за что его берут: находит дефекты, которые иначе дожили бы до следующего мажорного релиза. Проблема в арифметике ресурсов: находки приходят пачкой в тот момент, когда запас времени на исправление минимален.
Чем это не является: вайб-кодинг ни при чём
К вайб-кодингу проблемы отношения не имеют: код писали задолго до того, как этот подход появился. LLM здесь выступает инструментом ревью, а не автором строк. Разделять эти два явления важно, иначе легко сделать вывод «нейросеть написала код с ошибками», который к реальности отношения не имеет.
Что перенесли в PostgreSQL 20 и что осталось в PostgreSQL 19
До переноса из версии убрали 8-10 крупных функций. Это не единичный случай, крупные доработки регулярно выпадают из релиза на этапе беты, но обычно не в таком количестве и не за один цикл.
| Функция | Где окажется | Почему |
|---|---|---|
| SQL/PGQ | PostgreSQL 20 | запросы к графам свойств из стандарта SQL, перенесены в следующий мажор |
| GROUP BY ALL | PostgreSQL 20 | ошибка, при которой запрос возвращал неверный результат |
| Слияние и разделение партиций (MERGE/SPLIT PARTITION) | PostgreSQL 20 | перенесены вместе с другими крупными функциями |
| REPACK CONCURRENTLY | PostgreSQL 19 | остаётся в релизе |
| Логическая репликация последовательностей | PostgreSQL 19 | остаётся в релизе |
| pg_plan_advice | PostgreSQL 19 | остаётся в релизе |
SQL/PGQ, GROUP BY ALL и партиции: что уехало в PostgreSQL 20
GROUP BY ALL показателен как индикатор: причиной стала не нехватка времени, а корректность. Функция возвращала неверный результат в части сценариев, выпускать её в таком виде нельзя, и перенос в PostgreSQL 20 здесь честнее, чем тихое исправление после релиза (детали переносов).
SQL/PGQ это поддержка запросов к графам свойств из стандарта SQL. Её ждали те, кто хранит связи между сущностями в реляционной базе и не хочет тащить рядом отдельную графовую СУБД. Слияние и разделение партиций упрощает обслуживание секционированных таблиц: без таких операций изменение границ секций обычно делают вручную, через создание новых таблиц и перенос данных.
REPACK CONCURRENTLY, логическая репликация последовательностей и pg_plan_advice: что осталось
В релизе остаются три заметные вещи. REPACK CONCURRENTLY - перепаковка таблиц и индексов без длительной блокировки, то есть возможность убрать раздувание и вернуть место на диске, не останавливая нагрузку. Логическая репликация последовательностей закрывает старую боль: счётчики в логическую репликацию не попадали, и после переключения на реплику их приходилось поправлять руками. pg_plan_advice связан с работой с планами запросов.
Синтаксис и детали этих функций лучше смотреть в документации к RC-сборкам, а не в пересказах: до финального релиза поведение ещё может измениться.
Что это значит для тех, кто планирует обновление
Кому стоит ждать PostgreSQL 19
Ждать 19 имеет смысл, если вам нужны именно оставшиеся в ней функции: перепаковка без блокировок, логическая репликация последовательностей, pg_plan_advice. Второй случай - вы не привязаны к жёстким срокам и готовы тестировать новую версию на своих нагрузках уже после 19 ноября.
Кому перенос дат не критичен
Если в вашем плане обновления стояли SQL/PGQ, GROUP BY ALL или операции слияния и разделения партиций, ждать 19 ноября бессмысленно: этих функций в релизе не будет, ориентируйтесь на PostgreSQL 20. Если обновление плановое и не срочное, спокойно оставайтесь на текущей версии: дата релиза сама по себе ценности не создаёт.
Что стоит сделать сейчас, не дожидаясь 19 ноября:
- проверить, не заложены ли в планы функции, которые уехали в 20;
- прогнать свои расширения и типовые запросы на RC-сборке в стейдже;
- не привязывать критичные миграции к 19 ноября: между RC2 12 ноября и релизом всего неделя, а исправления вливаются до последнего;
- учесть, что бета была сжатой, и заложить больше времени на проверку нетипичных сценариев.
Почему пока разумно оставаться на PostgreSQL 18
Аргументы за PostgreSQL 18
Первый аргумент: 19 выходит позже и в урезанном виде, часть ожидаемых функций уехала в 20, так что прирост возможностей меньше запланированного. Второй: бета была короче обычного из-за исправления уязвимостей с апреля по август, а значит, нетипичные сценарии проверены хуже. Третий: 18 уже обкатана на реальных нагрузках, и миграция на неё предсказуемее, чем прыжок на свежий мажор в декабре.
Текущую рекомендацию обновляться на PostgreSQL 18 даёт Snowflake, которая следит за релизным циклом. Это внешний ориентир, а не официальное требование проекта PostgreSQL, и принимать его как абсолютную истину не стоит.
Когда совет не подходит
Оставаться на 18 невыгодно, если вам критичны функции, которые остались в 19: перепаковка без блокировок экономит окна обслуживания, логическая репликация последовательностей снимает ручные правки при переключении, pg_plan_advice нужен для работы с планами. Второй случай: вы уже тестируете 19 и ваши сервисы зависят от её поведения. Третий: внутренняя политика требует держать максимально свежую мажорную версию. В этих ситуациях решение другое, и общая рекомендация его не заменит.
Что дальше: LLM-ревью и релизный цикл PostgreSQL
Разовая история или новый фактор релизного цикла
Официально связь задержки с ИИ не подтверждена, поэтому прогнозировать волну похожих переносов рано. Данных для тренда нет: один релиз, одно частное мнение, никакой статистики по количеству найденных дефектов. Что уже видно: LLM-ревью добавляет мейнтейнерам работу, и в проектах с длинной историей кода эта работа приходит неравномерно, пачками перед релизом.
Для открытой разработки это ставит вопрос приоритетов. Находки ценные, но превращать их в патчи некому, кроме тех же людей, которые отвечают за дату релиза. Как проекты будут с этим справляться, покажет следующий цикл.
Короткое резюме и что делать читателю
Ключевые даты: RC1 15 октября, RC2 12 ноября, релиз 19 ноября. SQL/PGQ, GROUP BY ALL и слияние с разделением партиций уехали в PostgreSQL 20. В 19 остаются REPACK CONCURRENTLY, логическая репликация последовательностей и pg_plan_advice. Официальная причина переноса - объём исправлений; версия про LLM-ревью принадлежит Питеру Эйзентрауту и остаётся его личным мнением.
План действий короткий: сверить свои планы с таблицей переносов, протестировать RC-сборку в стейдже, не привязывать критичные миграции к 19 ноября и не спешить уходить с 18, если только вам не нужны конкретные функции из 19.