PostgreSQL 19 виходить без SQL/PGQ: правильне рішення

Кожен, хто керував Postgres-первинним сервером обсягом понад терабайт, дивився на звіт про роздуття та рахував час простою. Можна або змиритися зі зростанням диска, або запланувати вікно обслуговування, якого ніхто не хоче, або вдатися до стороннього інструменту й сподіватися, що топологія реплікації витримає. PostgreSQL 19 нарешті вирішує цю проблему на рівні ядра. Але водночас тихо відмовляється від однієї гучної функції, яка просто не була готова.

Суть проблеми

Коротко: як повідомляє The Register, розробники PostgreSQL прибрали заплановану підтримку графових запитів SQL/PGQ з версії 19 через незакриті баги; четверта бета-версія виходить 24 вересня, а остаточна дата релізу досі не підтверджена. Давній контрибьютор Том Лейн висловився прямо: «Я готовий посперечатися на вечерю, що якщо ми випустимо це у v19, після релізу знайдуться баги, які неможливо буде виправити до v20.» Том Кінкейд, SVP з розробки програмного забезпечення в EDB, підтвердив виключення і сказав, що спільнота хотіла опрацювати ще кілька речей перед випуском.

SQL/PGQ важливий, бо у 2023 році він став частиною стандарту SQL і забезпечує портативний синтаксис для запитів до вузлів і ребер без виходу за межі реляційного двигуна. Для команд, які тримали окрему графову базу даних поряд з Postgres — для виявлення шахрайства, мереж KYC, афілійних ієрархій або шляхів атрибуції в рекламних технологіях — обіцянка була суттєвою: прибрати sidecar, зберегти одне джерело правди, одну стратегію резервного копіювання, одну HA-схему. Ця обіцянка тепер переноситься на версію 20.

Тим часом операційний біль, який ніколи не потрапляв на маркетингові слайди, — це те, що цей реліз справді виправляє. VACUUM FULL переписує таблицю, щоб повернути простір, зайнятий застарілими версіями рядків, і повернути його операційній системі. Весь цей час він утримує ексклюзивне блокування таблиці, блокуючи будь-яке читання і будь-який запис. На активній OLTP-таблиці це не операція обслуговування. Це аварійний простій із прикріпленим тікетом на зміну.

Кінкейд описав сценарій, який я спостерігав на десятках чергових ротацій: «Нічні дзвінки були наслідком того, що хтось виконував VACUUM FULL, і клієнти не могли отримати доступ до даних, або хтось хотів знати, чому це взагалі запущено.» Кожен DBA, хто це читає, щойно кивнув. Роздуття накопичується, autovacuum не встигає на таблиці з великою кількістю змін, хтось зрештою запускає VACUUM FULL — і спрацьовує пейджер.

Доступні варіанти

До версії 19 у команд було три реалістичні варіанти повернення простору на активній таблиці, і жоден з них не був приємним.

Варіант перший: запланувати VACUUM FULL і змиритися з простоєм. Це підходить для внутрішніх звітних таблиць або всього, що можна заморозити у вікно з низьким трафіком. Для оператора iGaming із живими ставками або фінтех-компанії, що обробляє позиції, немає вікна з низьким трафіком, яке тривало б досить довго. Виробничі інциденти, які я бачив, зазвичай починаються саме тут — коли хтось припускає, що «це займе мало часу» на таблиці розміром 400 ГБ.

Варіант другий: pg_repack як розширення. Це розширення спільноти роками виконувало роботу з конкурентного перезапису, і воно працює. Але воно також додає операційне навантаження: встановлення та версіонування розширення на кожній репліці, моніторинг тимчасових таблиць, обробка крайніх випадків з реплікаційними слотами, і сподівання, що ваш провайдер керованого Postgres підтримує його. Деякі підтримують, деякі ні. Коли перезапис зупиняється на пів шляху, очищення ручне й нервове.

Варіант третій: партиціювати таблицю та видаляти старі партиції. Це правильна довгострокова відповідь для часових рядів і переважно дописуваних навантажень, і це має бути стандартом для будь-якої таблиці, яка, за очікуванням, перевищить кілька сотень гігабайт. Але це не допомагає вам сьогодні з наявною великою таблицею, яку ніколи не партиціювали. Ретрофітне партиціювання на живій таблиці розміром 2 ТБ — це окремий багатотижневий проєкт.

PostgreSQL 19 додає четвертий варіант: нову команду REPACK з модифікатором CONCURRENTLY. Звичайний REPACK поводиться як VACUUM FULL і утримує ексклюзивне блокування протягом усієї операції. REPACK CONCURRENTLY дозволяє іншим транзакціям звертатися до таблиці впродовж більшої частини операції і потребує лише короткого ексклюзивного блокування під час підміни перезаписаних файлів таблиці та індексів. Саме такого роду операцію команди хотіли бачити в ядрі протягом десяти років.

Моя думка: це тихо переносить функцію pg_repack до базового дистрибутива, що є більшою справою для клієнтів керованих баз даних, ніж для тих, хто розгортає самостійно. Якщо ви працюєте на хмарному провайдері, який традиційно повільно додає розширення до білого списку, тепер ви отримаєте конкурентний repack, щойно вони перейдуть на 19. Це одна менша розмова про закупівлі і один менший режим відмови у вашому runbook.

Щодо SQL/PGQ — альтернативи залишаються незмінними. Продовжуйте використовувати наявне сховище графів (Neo4j, Memgraph, AGE на Postgres) або моделюйте зв'язки за допомогою рекурсивних CTE і платіть податок планувальника запитів. Нічого нового в цьому циклі оцінювати не треба. Повертайтеся до цього питання у версії 20. Перегляньте документацію PostgreSQL, коли вийдуть примітки до релізу, щоб дізнатися точний синтаксис REPACK.

Що інженерним командам варто зробити насправді

По-перше, не переписуйте дорожні карти навколо SQL/PGQ. Якщо ваш план на 2026 рік передбачав відмову від графового sidecar у четвертому кварталі, цей план мертвий. Перенесіть міграцію на кінець 2027 року в найкращому разі, за умови, що версія 20 виходить у звичайному річному ритмі і PGQ справді до неї потрапить. Ставки на невипущені функції обпалювали команди, з якими я працював, більше разів, ніж можу порахувати. Цитата Лейна про «вечерю» — це ввічлива інженерна мова на позначення «це нас переслідуватиме». Поважайте це.

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

По-третє, ставтеся до оновлення до версії 19 як до двофазного розгортання. Фаза перша: перейдіть на 19 на репліках для читання та некритичних кластерах, перевірте інструменти резервного копіювання та PITR, переконайтеся, що моніторинг фіксує нову команду. Фаза друга: запустіть REPACK CONCURRENTLY на клоні staging вашої найбільш роздутої таблиці та виміряйте реальну тривалість короткого ексклюзивного блокування на етапі підміни. «Зазвичай утримується лише короткочасно» — це формулювання документації. Ваше конкретне залізо, реплікаційна затримка та профіль конкуренції за блокування визначають, що «короткочасно» означає для вас.

По-четверте, якщо ви зараз платите за сторонній інструмент repack або рівень управління розширеннями, який існує переважно для підтримки pg_repack, поставте на календар перегляд через шість місяців після оновлення. Можливо, вдасться спростити стек.

Підводні камені та крайні випадки

Короткочасне ексклюзивне блокування на етапі підміни файлів — це все одно блокування. На таблиці з SLO за затримкою в субмілісекунди та великою кількістю конкурентних записів навіть коротке блокування може поставити в чергу достатньо транзакцій, щоб спрацював пул з'єднань. Тестуйте під навантаженням, характерним для виробництва, а не на синтетичному бенчмарку. Невтішна правда: команди, які сприймають «concurrent» як «нульовий вплив», отримують сюрпризи.

Друге, що варто перевірити — поведінка реплікації. Будь-яка операція, що переписує таблицю, генерує значний обсяг WAL. Якщо ваші репліки географічно віддалені або мають обмежену пропускну здатність, плануйте стрибок затримки під час repack і переконайтеся, що ваш трафік на читання може його витримати або перемкнутися без збоїв. Розгляньте можливість запуску OpenTelemetry-спанів навколо операції, щоб можна було зіставити затримку застосунку з вікном перезапису.

По-третє, стежте за вільним місцем на диску. Конкурентний перезапис потребує достатньо вільного місця для зберігання другої копії таблиці разом з індексами до завершення підміни. На таблиці 500 ГБ із трьома індексами це не похибка округлення. Заздалегідь виділіть місце, інакше операція зупиниться посередині і залишить вас прибирати наслідки.

Нарешті, не пропускайте бета-тестування, тому що «це просто команда repack». Той самий потяг релізу, який породив достатньо занепокоєння, щоб прибрати SQL/PGQ, постачає і REPACK. Запустіть бету 4 на копії вашого навантаження після 24 вересня. Краще знайти крайній випадок самостійно, ніж о третій ночі, поки клієнти чекають.

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

• SQL/PGQ виключено з версії 19. Будь-який пункт дорожньої карти, що передбачав нативні графові запити в Postgres цього року, потрібно перенести на версію 20 або повернутися до наявних графових сховищ і рекурсивних CTE.
• REPACK CONCURRENTLY — непомітна зіркова функція. Вона переносить роботу pg_repack до ядра, потребуючи лише короткого ексклюзивного блокування при підміні файлів замість повного блокування, яке вимагає VACUUM FULL.
• Проаудитуйте роздуття перед оновленням. Підготуйте пріоритизований список таблиць для першочергового перезапису, щоб діяти в перший квартал після оновлення, а не метушитися.
• Тестуйте вікно підміни під навантаженням. «Короткочасно» залежить від навантаження. Виміряйте тривалість блокування на staging із реалістичною конкурентністю, перш ніж запускати на таблиці, яку бачать клієнти.
• Підтримайте рішення про виключення. Прибрати нестабільну гучну функцію до релізу — це правильне рішення. Саме так має поводитися база даних, якій ви довіряєте гроші та дані клієнтів.