// the find
citusdata/pg_cron
Run periodic jobs in PostgreSQL
pg_cron is a PostgreSQL extension that runs a background worker which reads a cron.job table and executes SQL on a cron schedule, so routine maintenance like vacuums, partition rotation, and rollups runs next to the data it touches. It is aimed at teams already on Postgres who would rather not run a separate scheduler just to call a function every night.
- Schedule parsing comes from Paul Vixie's cron, so the syntax is familiar to most ops people. It also adds an interval form ('10 seconds') that stock crontab can't express.
- Jobs are rows in cron.job under an RLS policy, so non-superusers can schedule and see only their own jobs without touching the OS crontab.
- Only one instance of a given job runs at a time, and a second trigger queues behind the first. That prevents the overlapping-run pileup that bites most hand-rolled schedulers.
- cron.job_run_details records status, return message, and timing for every run, so monitoring is a SQL query instead of a log grep.
- The default path opens a libpq connection to localhost, which only works cleanly if pg_hba trusts local connections or the job's user has a .pgpass. Background workers avoid that, but they are capped by max_worker_processes, so you trade one footgun for a capacity limit.
- cron.job_run_details is never pruned automatically. The README's fix is a scheduled DELETE job, which works until someone forgets to add it and a 5-second job fills the table for a year.
- Only one database per cluster can hold the metadata tables, so multi-tenant or database-per-service setups need cron.schedule_in_database and a clear picture of which database owns the job table.
- Failover does not resume work. The README's sample shows a run marked failed with 'server restarted', so any non-idempotent job needs its own guard against a half-finished run.