Postgres 19 Beta: REPACK в ядре и эволюция Autovacuum

Любой, кто хоть раз назначал окно обслуживания в 3 часа ночи ради запуска VACUUM FULL на раздутой таблице заказов, знает: реальная стоимость операций в Postgres — это не лицензионные платежи, а человеко-часы, потраченные на слежку за блокировками. Именно через эту призму и стоит читать бету Postgres 19. Главная фича — не блестящие SQL-запросы к графам свойств, а скучная «сантехника», которая наконец-то переехала в ядро.

Бета вышла в июне, и самая важная строка в примечаниях к выпуску для платформенных команд — это трёхсловная команда: REPACK CONCURRENTLY. Мой вывод: этот релиз по-тихому закрывает целый класс инцидентов в 2 часа ночи.

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

Postgres 19 вошёл в стадию беты с перечнем функций, похожим на вишлист, составленный из десятилетия боевых историй, — как подробно разобрал Snowflake в обзорной статье Крейга Керстиенса от 18 июня 2026 года. Центральная функция для операционных команд — новая команда REPACK, встроенная прямо в ядро, включая REPACK CONCURRENTLY. Годами ответом на раздутие таблиц без простоя был pg_repack — стороннее расширение, закрывавшее пробел, который экосистема не могла игнорировать. Теперь этот пробел закрыт.

Партиционирование получило два давно запрошенных оператора. ALTER TABLE ... MERGE PARTITIONS позволяет объединить orders_2026_q1 и orders_2026_q2 в единую orders_2026_h1. ALTER TABLE ... SPLIT PARTITION позволяет разбить orders_2026_q3 на три ежемесячных дочерних партиции. Никаких дампов, перезагрузок и кастомных скриптов миграции.

Логическая репликация продолжила поступательное развитие. Значения последовательностей теперь синхронизируются между издателями и подписчиками, публикации поддерживают ALL SEQUENCES, добавлено корректное сообщение об ошибках синхронизации последовательностей, а поведение обновления подписок в отношении последовательностей стало более строгим. Публикации также получили оператор EXCEPT, позволяющий публиковать всё, кроме нескольких указанных таблиц. Кроме того, wal_level = replica теперь может автоматически повышаться до логического уровня при необходимости, а новый параметр effective_wal_level сообщает, что фактически происходит под капотом.

Автовакуум получил самую масштабную структурную переработку за последние годы. Параллельные воркеры вакуума теперь доступны автовакууму и управляются параметром autovacuum_max_parallel_workers. Новая система оценки определяет порядок обработки таблиц — её можно настраивать для каждой таблицы через autovacuum_vacuum_insert_score_weight и autovacuum_vacuum_score_weight, а результаты видны в новом представлении pg_stat_autovacuum_scores. Керстиенс назвал REPACK CONCURRENTLY «одной из тех функций, которые для production-пользователей Postgres важнее, чем среднестатистический читатель примечаний к релизу мог бы ожидать». Детали ещё могут измениться до GA.

Техническая анатомия

Начнём с REPACK. Историческая проблема проста: VACUUM FULL перезаписывает таблицу, но при этом берёт блокировку ACCESS EXCLUSIVE — а значит, каждый запрос, каждый пул соединений, каждый нижестоящий сервис зависает. pg_repack обходил это ограничение, создавая теневую таблицу, воспроизводя изменения через триггеры и выполняя финальный своп под кратковременной блокировкой. Это работало, но было расширением, которое нужно было устанавливать, версионировать и которому нужно было доверять при крупных обновлениях. Перенос этого паттерна в ядро означает, что логику свопа теперь поддерживают те же люди, которые поддерживают слой хранения. Меньше сюрпризов при обновлении с 19 на 20.

Слияние и разбиение партиций — операционный эквивалент той же проблемы. Раньше изменение схемы партиционирования на лету означало самописный скрипт: создать новые партиции, скопировать строки пакетами, отсоединить старые и надеяться, что во время свопа ничего не запишется. Новый синтаксис сворачивает всё это в единый DDL-оператор. Пример из бета-документации стоит запомнить:

ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;

И обратное разбиение на orders_2026_07, orders_2026_08, orders_2026_09. Окна хранения данных больше не являются неизменным архитектурным решением.

Изменения в автовакууме более тонкие, но, пожалуй, более важные. Настройка autovacuum_max_parallel_workers = 4 позволяет одному запуску автовакуума распределить работу по нескольким воркерам для одной таблицы. Для широкой таблицы с несколькими индексами это разница между вакуумом, который завершается до следующего всплеска записи, и вакуумом, который не завершается. Новая система оценки с весами вроде autovacuum_vacuum_insert_score_weight = 3.0 и autovacuum_vacuum_score_weight = 0.5 позволяет сказать Postgres «таблицы с интенсивной вставкой важнее для меня, чем таблицы с интенсивным обновлением» — или наоборот. pg_stat_autovacuum_scores наконец раскрывает очередь, которую Postgres и так вычислял внутри себя. VACUUM VERBOSE и логи автовакуума теперь включают данные об использовании памяти и параллелизме. Отдельный параметр log_autoanalyze_min_duration позволяет логировать медленные операции анализа, не захлёбываясь в спаме от вакуума. Актуальный справочник по параметрам смотрите в документации Postgres по мере её приближения к GA.

Кто пострадает

Первыми — вендоры расширений. pg_repack долгое время был стандартом как в управляемых предложениях Postgres, так и в самостоятельно разворачиваемых стеках. Когда REPACK в ядре стабилизируется, ценностное предложение расширения сожмётся до «мы всё ещё поддерживаем Postgres 13». Это сужающийся рынок. Командам, построившим внутренний инструментарий поверх триггеров pg_repack, придётся решить: мигрировать на REPACK в ядре или поддерживать собственный форк.

Следом идут команды, работающие с большими партиционированными таблицами без надлежащего инструментария. Если ваша нагрузка — это логи сессий iGaming, реестры транзакций fintech или таблицы показов ad-tech, у вас почти наверняка есть схема партиционирования, которая имела смысл два года назад, но не сейчас. Производственные инциденты вокруг удержания партиций, которые я наблюдал, почти всегда восходят к одной и той же первопричине: кто-то выбрал ежемесячные партиции, тогда как правильными были бы еженедельные, и никто не хотел к этому прикасаться, потому что миграция выглядела слишком пугающей. Postgres 19 убирает это оправдание. А значит, технический долг теперь становится видимым долгом.

Третья группа — пользователи логической репликации, столкнувшиеся с проблемой последовательностей. Если вы проводили переключения blue-green, после которых приходилось вручную выполнять SELECT setval(...) для сотни последовательностей, этот ритуал наконец поддаётся автоматизации. Неудобный вывод: несколько runbook'ов восстановления после сбоев, которые я изучал в fintech-компаниях, по-прежнему предполагают ручное согласование последовательностей. Эти runbook'и теперь устарели, но никто их не обновит, пока аудит не вынудит это сделать.

Провайдеры управляемого Postgres испытывают более тонкое давление. Их дифференциация на операционных функциях (кастомная настройка вакуума, проприетарное управление раздутием) только что сократилась. Core Postgres поглощает их преимущество — релиз за релизом. Это хорошо для клиентов и неудобно для прайс-листов.

Playbook для инженерных команд

Первое: не обновляйте production на бету. Это очевидно, и я всё равно это скажу, потому что кто-нибудь всегда пробует. Но поднимите инстанс Postgres 19 beta в staging уже на этой неделе и воспроизведите на нём репрезентативную нагрузку. Цель не в том, чтобы подтвердить готовность к GA, а в том, чтобы заранее выявить изменения в поведении — особенно в части оценки автовакуума.

Второе: проведите аудит зависимостей от pg_repack. Составьте список всех окружений, где установлено расширение, всех cron-задач, которые его вызывают, всех runbook'ов, которые на него ссылаются. Составьте план миграции на REPACK CONCURRENTLY в ядре уже сейчас, даже если реализуете его только в 2027 году. Смена синтаксиса невелика, смена ментальной модели — нет.

Третье: пересмотрите схемы партиционирования свежим взглядом. Если вы мирились с неудобными размерами партиций, потому что исправление было слишком инвазивным, добавьте задачу в бэклог для миграции на GA Postgres 19. Объедините недоиспользуемые партиции, разбейте перегруженные.

Четвёртое: проведите бенчмарк автовакуума с параллельными воркерами на ваших самых больших таблицах. Начните консервативно: autovacuum_max_parallel_workers = 2, следите за насыщенностью I/O, затем увеличивайте. Устанавливайте веса оценки в зависимости от того, какая нагрузка у вас преобладает — вставка или обновление, — и используйте pg_stat_autovacuum_scores для проверки соответствия очереди вашим ожиданиям.

Пятое: обновите runbook'и логической репликации, убрав шаги ручного согласования последовательностей после перехода на 19. Затем протестируйте сценарии отказов: что именно показывает отчётность об ошибках синхронизации последовательностей и улавливает ли это ваша система алертинга?

Ключевые выводы

• REPACK CONCURRENTLY в ядре устраняет зависимость от расширения с десятилетней историей и убирает частый источник ночных окон обслуживания.
• ALTER TABLE ... MERGE PARTITIONS и SPLIT PARTITION делают схемы партиционирования изменяемыми без самописных скриптов миграции.
• Параллельные воркеры автовакуума вместе с новой системой оценки (и pg_stat_autovacuum_scores) впервые дают операционным командам реальные рычаги управления раздутием.
• Логическая репликация наконец корректно обрабатывает синхронизацию последовательностей, закрывая известную ловушку при переключениях для миграций и HA-конфигураций.
• Бета означает, что детали могут измениться до GA. Тестируйте в staging уже сейчас, но не переписывайте производственные runbook'и до стабилизации релиза.