pg_timetable: перенос планирования фоновых задач и скриптов внутрь PostgreSQL

В инфраструктурной практике сопровождения реляционных баз данных запуск регламентных процедур традиционно возлагается на системный планировщик cron хостовой операционной системы либо на внешние распределенные очереди задач (Celery, BullMQ, Temporal). Однако оба подхода несут скрытые эксплуатационные издержки: конфигурации crontab размазываются по серверам, пароли подключения к базе оседают в незашифрованных текстовых файлах, а при отказе хоста или переключении мастера (failover) регламентные задачи перестают выполняться вовсе.

Автономный планировщик pg_timetable, разрабатываемый компанией Cybertec, предлагает альтернативную модель: полностью перенести расписание, логику выполнения и историю запусков непосредственно внутрь PostgreSQL. Демон pg_timetable запускается рядом с базой или в контейнере, считывает задания из системных таблиц СУБД и управляется стандартными SQL-командами без правки конфигурационных файлов на хосте.

Декларативное расписание через timetable.add_job()

Вся конфигурация задач в pg_timetable сводится к вызову системной функции timetable.add_job(). Планировщик поддерживает стандартный 5-позиционный синтаксис cron, интервальные текстовые выражения и события перезапуска:

-- 1. Выполнение SQL-функции каждый день в 00:05 в августе
SELECT timetable.add_job(
  'execute-func', 
  '5 0 * 8 *', 
  'SELECT public.process_monthly_reports()'
);

-- 2. Регламентный запуск VACUUM каждые 2 часа в ночное время
SELECT timetable.add_job(
  'run-vacuum', 
  '23 0-20/2 * * *', 
  'VACUUM ANALYZE'
);

-- 3. Обновление материализованного представления каждые два часа
SELECT timetable.add_job(
  'refresh-matview', 
  '@every 2 hours', 
  'REFRESH MATERIALIZED VIEW CONCURRENTLY public.sales_summary'
);

-- 4. Очистка временного лога при старте планировщика
SELECT timetable.add_job(
  'clear-log', 
  '@reboot', 
  'TRUNCATE TABLE public.temp_sync_log'
);

Каждое задание регистрируется как строка в таблицах схемы timetable, благодаря чему расписание автоматически тиражируется на резервные узлы через стандартную репликацию PostgreSQL. Если основной сервер выходит из строя, при промоуте реплики планировщик мгновенно продолжает работу с актуальным набором задач.

Запуск системных утилит и внешних программ

Существенным преимуществом pg_timetable перед расширением pg_cron является способность запускать не только SQL-выражения, но и системные бинарные файлы операционной системы через параметр job_kind := 'PROGRAM'.

Это позволяет планировать регламентное обслуживание инфраструктуры — например, утилиту перестроения индексов reindexdb — с передачей структурированных аргументов через формат JSONB:

-- Запуск системной утилиты reindexdb каждое воскресенье в полночь
SELECT timetable.add_job(
  'reindex-maintenance',
  '0 0 * * 7',
  'reindexdb',
  '["--table=orders", "--dbname=production", "--verbose"]'::jsonb,
  'PROGRAM'
);

-- Вызов shell-скрипта с безопасной передачей параметров окружения
SELECT timetable.add_job(
  'backup-wal-archive',
  '0 */4 * * *',
  'bash',
  '["-c", "/usr/local/bin/wal-g backup-push /var/lib/postgresql/data"]'::jsonb,
  'PROGRAM'
);

Защита от параллельного запуска и аудит

Для тяжелых аналитических процедур и задач обслуживания диска pg_timetable предоставляет встроенный механизм предотвращения конкурентных запусков: если предыдущая итерация задачи еще выполняется, новая не стартует до ее полного завершения, исключая деградацию дисковой подсистемы.

Кроме того, инструмент обеспечивает строгий аудит:

• точное время начала и окончания каждой операции;
• код возврата процесса или статус выполнения SQL-транзакции;
• текст перехваченных ошибок и стандартного вывода (stdout/stderr);
• умные повторы (retries) с настраиваемой экспоненциальной задержкой.

Для команд, стремящихся упростить сопровождение PostgreSQL и исключить зависимость от системного cron, pg_timetable выступает зрелым решением, превращающим СУБД в самодостаточный центр автоматизации.