Чекап партиций перед праздниками

Представьте: 1 января, 00:20. Куранты пробили, праздник в самом разгаре, и тут звонок - не создаются платежи. Вся страна отмечает, а ты срочно подключаешься к vpn, и выясняешь, что в одной из журнальных таблиц… просто закончились партиции. Запись данных остановилась. Хотя есть и мониторинги и механизм автосоздания партиций.

Эта история — моя личная. И она научила меня одному: наше спокойствие в праздники — в наших руках. Лучше потратить 15 минут на проверку сейчас, чем отвлекаться на инциденты в праздники.

Поэтому начнём предпраздничный чекап PostgreSQL с партиций.

Этот запрос инвентаризирует прямых потомков партиционированных таблиц и эвристически выбирает последнюю текстовую верхнюю границу:

WITH partitions AS (
    SELECT np.nspname AS parent_schema, parent.relname AS parent_table,
           nc.nspname AS partition_schema, child.relname AS partition_table,
           pg_get_expr(child.relpartbound, child.oid) AS partition_bound
    FROM pg_inherits
      JOIN pg_class parent ON pg_inherits.inhparent = parent.oid
      JOIN pg_class child  ON pg_inherits.inhrelid  = child.oid
      JOIN pg_namespace np ON parent.relnamespace = np.oid
      JOIN pg_namespace nc ON child.relnamespace = nc.oid
    WHERE parent.relkind = 'p'
),
parsed_bounds AS (
    SELECT parent_schema, parent_table, partition_schema, partition_table, partition_bound,
           substring(partition_bound FROM '[tT][oO]\s*\((.*?)\)' ) AS upper_bound
    FROM partitions
),
ranked AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY parent_schema, parent_table
              ORDER BY upper_bound DESC NULLS LAST, partition_bound DESC) AS rn
    FROM parsed_bounds
)
SELECT
    parent_schema || '.' || parent_table AS table_name,
    partition_schema || '.' || partition_table AS last_partition,
    partition_bound AS bound_def, upper_bound AS max_val_bound
FROM ranked
WHERE rn = 1
ORDER BY bound_def, max_val_bound;

На что смотреть в результатах?

Взгляните на max_val_bound. Для простой RANGE-схемы по одной ISO-дате значение вроде '2026-01-01' означает, что записи с этой границы уже не попадут в предыдущую партицию.

Запрос разбирает результат pg_get_expr как текст. Это удобная шпаргалка, а не универсальный анализатор: составные ключи, LIST/HASH, DEFAULT, MINVALUE/MAXVALUE, приведения типов и многоуровневое партиционирование требуют отдельной проверки. Сверьте DDL последних нескольких партиций и выполните тестовую вставку с датой за ожидаемой границей в контролируемой транзакции.

Что проверить кроме границы

• Кто и когда создаёт следующую партицию, что произойдёт после ошибки этой джобы.
• Есть ли DEFAULT-партиция и мониторится ли попадание строк в неё.
• Созданы ли на новых партициях нужные индексы, ограничения, права и настройки autovacuum.
• Хватает ли партиций на весь период дежурств с безопасным запасом.

Пятнадцать минут такой проверки дешевле аварийного DDL в праздничную ночь.