pg_cron多物化视图刷新阻塞其他定时任务问题排查

pg_cron 默认配置下，max_running_jobs 参数值为1，意味着同一时间仅能运行一个定时任务。当MV1的刷新任务耗时超过5分钟（比如25分钟）时，它会持续占用pg_cron唯一的工作进程，导致后续触发的MV2定时任务、每分钟测试任务都无法获取空闲进程，只能处于排队等待状态，无法启动。而手动执行MV2的并发刷新是在当前数据库会话中直接运行，不占用pg_cron的工作进程资源，因此不受影响。

1. 调整pg_cron并发任务数 #

修改PostgreSQL配置文件中的pg_cron.max_running_jobs参数，增大允许同时运行的定时任务数量：

• 编辑postgresql.conf，添加或修改：

  pg_cron.max_running_jobs = 5  # 根据实际需求设置，比如3-5个
  

• 执行命令重新加载配置，无需重启数据库：

  SELECT pg_reload_conf();
  

注意：参数值不要设置过大，避免过多并发定时任务抢占数据库资源，影响整体性能。

2. 优化MV1的刷新性能，缩短执行耗时 #

针对MV1的聚合查询进行性能优化，从根源上减少任务阻塞的概率：

• 为基表T1创建适配聚合逻辑的索引，比如针对聚合字段、过滤条件的组合索引，减少扫描的数据量
• 执行EXPLAIN ANALYZE REFRESH MATERIALIZED VIEW MV1;查看执行计划，定位瓶颈（如全表扫描、排序耗时、JOIN效率低等）并针对性优化
• 如果T1数据量较大，考虑按时间或业务维度对T1进行分区，降低聚合操作的数据范围
• 若MV1支持并发刷新（已创建唯一索引），确保使用REFRESH MATERIALIZED VIEW CONCURRENTLY MV1，避免刷新期间阻塞其他查询，但核心还是要优化聚合本身的效率

3. 调整MV1的定时周期 #

将MV1的刷新周期调整为大于其实际耗时的间隔，比如从5分钟改为30分钟，避免短周期任务重复触发后持续占用pg_cron进程，减少任务排队冲突的可能。

内容的提问来源于stack exchange，提问作者Locke Lamora