Postgres 19 Beta: REPACK у ядрі та еволюція Autovacuum

Кожен, хто хоч раз призначав вікно обслуговування о 3 ночі лише для того, щоб запустити VACUUM FULL на роздутій таблиці замовлень, знає: реальна ціна операцій Postgres — не ліцензійний збір, а людино-години на супроводі блокувань. Саме крізь цю призму варто розглядати Postgres 19 beta. Головна фіча — не блискучі SQL-запити до графів властивостей, а нудна сантехніка, яка нарешті переїхала до ядра.

Beta вийшла у червні, і реліз-нота, що має найбільше значення для платформних команд, — це команда з трьох слів: REPACK CONCURRENTLY. Моя думка: цей реліз тихо виводить цілий клас нічних інцидентів о 2 годині ночі.

Що трапилось

Postgres 19 увійшов у beta зі списком фіч, що схожий на вишлист зі скарбниці десятирічних виробничих «бойових» історій, як детально описав 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 отримав найбільше структурне доопрацювання за роки. Паралельні воркери vacuum тепер доступні для autovacuum, керовані параметром autovacuum_max_parallel_workers. Нова система оцінювання визначає порядок обробки, що налаштовується на рівні таблиці через autovacuum_vacuum_insert_score_weight та autovacuum_vacuum_score_weight, і відображається через нове представлення pg_stat_autovacuum_scores. Керстієнс описав REPACK CONCURRENTLY як «одну з тих фіч, що для виробничих користувачів Postgres важливіша, ніж може здатись пересічному читачу реліз-нот». Деталі ще можуть змінитися до GA.

Технічна анатомія

Почнемо з REPACK. Історична проблема проста: VACUUM FULL переписує таблицю, але бере блокування ACCESS EXCLUSIVE, тобто кожен запит, кожен пул з'єднань, кожен залежний сервіс зупиняється. pg_repack обходив це, створюючи тіньову таблицю, відтворюючи зміни через тригери та виконуючи підміну наприкінці під коротким блокуванням. Це працювало, але розширення потрібно було встановлювати, версіонувати і довіряти йому при мажорних оновленнях. Вбудовування цього шаблону в ядро означає, що логіка підміни тепер підтримується тими ж людьми, що підтримують шар зберігання. Менше сюрпризів при оновленні з 19 на 20.

Злиття та розбиття партицій — операційний еквівалент. Раніше зміна схеми партиціювання на льоту вимагала власноруч написаного скрипту: створити нові партиції, скопіювати рядки пакетами, від'єднати старі, сподіватись, що нічого не записується під час підміни. Новий синтаксис згортає все це в один DDL-оператор. Приклад із beta-документації варто запам'ятати:

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 тонші, але, мабуть, важливіші. Встановлення autovacuum_max_parallel_workers = 4 дозволяє одному запуску autovacuum розподілятись між кількома воркерами на одній таблиці. На широкій таблиці з декількома індексами це різниця між vacuum, що завершується до наступного сплеску записів, і тим, що не завершується. Нова система оцінювання з вагами на зразок autovacuum_vacuum_insert_score_weight = 3.0 та autovacuum_vacuum_score_weight = 0.5 дозволяє сказати Postgres «таблиці з великою кількістю вставок важливіші для мене, ніж ті, де багато оновлень», або навпаки. pg_stat_autovacuum_scores нарешті відкриває чергу, яку Postgres і так обчислював внутрішньо. VACUUM VERBOSE та логи autovacuum тепер містять деталі про використання пам'яті та паралелізм. Окремий параметр log_autoanalyze_min_duration дозволяє логувати повільні аналізи, не тонучи в спамі від vacuum. Дивіться документацію Postgres для довідки по параметрах по мірі наближення до GA.

Хто відчує наслідки

Насамперед — вендори розширень. pg_repack був стандартним компонентом як у керованих пропозиціях Postgres, так і в самостійно розгорнутих стеках. Як тільки REPACK буде стабільним у ядрі, ціннісна пропозиція розширення зводиться до «ми ще підтримуємо Postgres 13». Це ринок, що скорочується. Командам, які побудували внутрішні інструменти на основі тригерів pg_repack, потрібно буде вирішити: мігрувати на REPACK у ядрі чи підтримувати власний форк.

Далі — команди, що працюють із великими партиційованими таблицями без належного інструментарію. Якщо ваше навантаження — це логи сесій iGaming, журнали транзакцій фінтеху або таблиці показів ad-tech, ви майже напевно маєте схему партиціювання, що мала сенс два роки тому і вже не має. Виробничі інциденти, які я бачив навколо зберігання партицій, майже завжди зводяться до однієї першопричини: хтось обрав місячні партиції, коли правильними були б тижневі, і ніхто не хотів їх чіпати, бо міграція була надто страшною. Postgres 19 прибирає це виправдання. А отже, технічний борг стає видимим боргом.

Третя група — користувачі логічної реплікації на межі проблеми з послідовностями. Якщо ви проводили blue-green перемикання, після яких вручну виконували SELECT setval(...) для сотні послідовностей, цей ритуал нарешті можна автоматизувати. Незручне спостереження: кілька посібників із відновлення після аварій у фінтех-компаніях, які я переглядав, досі передбачають ручне узгодження послідовностей. Ці посібники тепер хибні, але ніхто їх не оновить, доки аудит не змусить це зробити.

Провайдери керованого Postgres відчувають тонший тиск. Їхня диференціація на операційних фічах (кастомне тонке налаштування vacuum, пропрієтарне управління роздуттям) щойно стисла. Ядро Postgres поїдає їхній рів, по одному релізу за раз. Це добре для клієнтів і незручно для сторінок із цінами.

План дій для інженерних команд

По-перше, не оновлюйте production до beta. Це очевидно, але я все одно скажу, бо хтось завжди пробує. Але поставте інстанс Postgres 19 beta на staging цього тижня та відтворіть на ньому репрезентативне навантаження. Мета не в тому, щоб підтвердити готовність до GA, а в тому, щоб якомога раніше виявити зміни в поведінці — особливо навколо оцінювання autovacuum.

По-друге, проаудіюйте залежності від pg_repack. Складіть список кожного середовища, де встановлено розширення, кожного cron-завдання, що його викликає, кожного посібника, що на нього посилається. Підготуйте міграцію на REPACK CONCURRENTLY у ядрі зараз, навіть якщо не будете виконувати її до 2027 року. Заміна синтаксису невелика, заміна ментальної моделі — ні.

По-третє, перегляньте свої схеми партиціювання свіжим поглядом. Якщо ви жили з незручними розмірами партицій, бо виправлення було надто інвазивним, додайте тікет у беклог для міграції на Postgres 19 GA. Злийте недовикористані партиції, розбийте перевантажені.

По-четверте, зробіть бенчмарк autovacuum з паралельними воркерами на ваших найбільших таблицях. Починайте консервативно: autovacuum_max_parallel_workers = 2, слідкуйте за насиченням I/O, поступово збільшуйте. Встановіть ваги оцінювання залежно від того, чи ваше навантаження переважно на вставку, чи на оновлення, і використовуйте pg_stat_autovacuum_scores для перевірки відповідності черги вашій інтуїції.

По-п'яте, оновіть посібники з логічної реплікації, прибравши кроки ручного узгодження послідовностей після переходу на 19. Потім перевірте режими збоїв: що насправді відображає звітування про помилки синхронізації послідовностей і чи вловлює це ваш алертинг?

Ключові висновки

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