Manage PostgreSQL Cron Jobs
Pigsty uses crontab to schedule routine backups, transaction freezing, and reorganization of bloated tables and indexes.
Quick Reference
| Operation | Quick Command | Description |
|---|---|---|
| Configure Cron Jobs | ./pgsql.yml -t pg_crontab -l <cls> | Apply pg_crontab config |
| View Cron Jobs | crontab -l | View as postgres user |
| Physical Backup | pg-backup [full|diff|incr] | Execute backup with pgBackRest |
| Transaction Freeze | pg-vacuum [database...] | Freeze aging transactions, prevent XID wraparound |
| Bloat Maintenance | pg-repack [database...] | Online reorganize bloated tables and indexes |
For other management tasks, see: Backup Management, Monitoring System, HA Management.
Configure Cron Jobs
Use pg_crontab to configure cron jobs for the PostgreSQL database superuser.
The pg_dbsu parameter selects this user; the default is postgres.
Example Configuration
The following pg-meta configuration schedules a full backup daily at 1:00 AM.
The pg-test configuration schedules a full backup on Monday and incremental backups on other days.
Recommended Maintenance Schedule
| Task | Frequency | Timing | Description |
|---|---|---|---|
pg-backup | Daily | Early morning | Full or incremental backup, depending on business needs |
pg-vacuum | Weekly | Sunday early morning | Freeze aging transactions, prevent XID wraparound |
pg-repack | Weekly/Monthly | Off-peak hours | Reorganize bloated tables/indexes, reclaim space |
The pg-backup, pg-vacuum, and pg-repack scripts detect the current node role automatically.
They run only on the primary. Replicas exit immediately.
Thus, you can configure the same cron jobs on all nodes.
After failover, the new primary automatically continues the scheduled maintenance tasks.
Apply Cron Jobs
The pg_crontab task in pgsql.yml writes cron jobs to the default location for the operating system:
- EL (RHEL/Rocky/Alma):
/var/spool/cron/postgres - Debian/Ubuntu:
/var/spool/cron/crontabs/postgres
Each playbook execution will fully overwrite the cron job configuration.
View Cron Jobs
Execute the following command as the pg_dbsu OS user to view cron jobs:
For explanations of crontab syntax, see Crontab Guru.
pg-backup
pg-backup is the Pigsty physical backup script.
It uses pgBackRest and supports full, differential, and incremental backups.
Basic Usage
Backup Types
| Type | Parameter | Description |
|---|---|---|
| Full Backup | full | Complete backup of all data, only this backup needed for recovery |
| Differential | diff | Backup changes since last full backup, recovery needs full + diff |
| Incremental | incr | Backup changes since last any backup, recovery needs complete chain |
Execution Requirements
- Script must run on primary as postgres user
- Script auto-detects current node role, exits (exit 1) when run on replica
- Auto-retrieves stanza name from
/etc/pgbackrest/pgbackrest.conf
Common Cron Configurations
For more backup and recovery operations, see the Backup Management section.
pg-vacuum
pg-vacuum is the Pigsty transaction freeze script.
It runs VACUUM FREEZE to prevent database shutdown caused by transaction ID (XID) wraparound.
Basic Usage
Command Options
| Option | Description | Default |
|---|---|---|
-h, --help | Show help message | - |
-n, --dry-run | Dry run mode, display only | false |
-a, --age | Age threshold, tables exceeding need freeze | 100000000 |
-r, --ratio | Aging ratio threshold, full freeze if exceeded (%) | 40 |
Logic
- Check the database
datfrozenxidage. Skip the database if its age is below the threshold. - Calculate the aging page ratio: table pages above the age threshold as a percentage of all pages.
- If the aging ratio exceeds 40%, run
VACUUM FREEZE ANALYZEon the full database. - Otherwise, run
VACUUM FREEZE ANALYZEonly on tables above the age threshold.
Script sets vacuum_cost_limit = 10000 and vacuum_cost_delay = 1ms to control I/O impact.
Execution Requirements
- Script must run on primary as postgres user
- Uses file lock
/tmp/pg-vacuum.lockto prevent concurrent execution - Auto-skips
template0,template1,postgressystem databases
Common Cron Configuration
pg-repack
pg-repack is the Pigsty bloat maintenance script.
It uses the pg_repack extension to reorganize bloated tables and indexes online.
Basic Usage
Command Options
| Option | Description | Default |
|---|---|---|
-h, --help | Show help message | - |
-n, --dry-run | Dry run mode, display only | false |
-t, --table | Reorganize tables only | false |
-i, --index | Reorganize indexes only | false |
-T, --timeout | Lock wait timeout (seconds) | 10 |
-j, --jobs | Parallel jobs | 2 |
Auto-Selection Thresholds
Script auto-selects objects to reorganize based on table/index size and bloat ratio:
Table Bloat Thresholds
| Size Range | Bloat Threshold | Max Count |
|---|---|---|
| < 256MB | > 40% | 64 |
| 256MB - 2GB | > 30% | 16 |
| 2GB - 8GB | > 20% | 4 |
| 8GB - 64GB | > 15% | 1 |
Index Bloat Thresholds
| Size Range | Bloat Threshold | Max Count |
|---|---|---|
| < 128MB | > 40% | 64 |
| 128MB - 1GB | > 35% | 16 |
| 1GB - 8GB | > 30% | 4 |
| 8GB - 64GB | > 20% | 1 |
The script skips tables and indexes larger than 64GB and shows a warning. Handle these objects manually.
Execution Requirements
- Script must run on primary as postgres user
- Requires
pg_repackextension installed (installed by default in Pigsty) - Requires
pg_table_bloatandpg_index_bloatviews inmonitorschema - Uses file lock
/tmp/pg-repack.lockto prevent concurrent execution - Auto-skips
template0,template1,postgressystem databases
Normal reads and writes continue during reorganization. However, the final switch requires an AccessExclusive lock on the table, which blocks all access. For high-throughput workloads, run the script during off-peak hours or maintenance windows.
Common Cron Configuration
Use the PGCAT Database - Table Bloat panel to check database bloat. Then select tables and indexes with high bloat for reorganization.
For more details see: Managing Relation Bloat
Remove Cron Jobs
When pgsql-rm.yml removes a PostgreSQL cluster, it automatically deletes the postgres user crontab file.
Related Documentation
- Backup Management: PostgreSQL backup and recovery
- Monitoring System: PostgreSQL monitoring and alerting
- Cluster Management: Cluster creation, scaling, and teardown
- Patroni Management: HA cluster management
Was this page helpful?
Thanks—your feedback helps us improve this page.
What got in the way? (optional)