pg_timetable定时任务异常：已创建的自定义函数定时任务次日无法运行

遇到这种前一天正常、第二天突然失效的问题确实挺闹心的，我帮你梳理几个常见的排查方向，一步步来定位问题：

• 先确认pg_timetable服务是否在运行
  大概率是服务意外停止了——比如重启机器后没设置开机自启、服务进程崩溃，或者服务器资源不足被系统杀掉了。你可以：

  • Linux系统用systemctl status pg_timetable查看状态，没运行的话用systemctl start pg_timetable启动，再加systemctl enable pg_timetable设置开机自启
  • Windows系统打开「服务管理器」，找到pg_timetable服务，检查状态并手动启动，同时设置启动类型为「自动」

• 验证任务是否还存在且配置正确
  有时候任务可能被误删，或者配置被意外修改。登录PostgreSQL执行以下查询确认：

  -- 查看任务基本信息
  SELECT job_id, jobname, schedule, enabled FROM timetable.job WHERE jobname = 'execute-func';
  -- 查看对应的执行步骤
  SELECT * FROM timetable.job_step WHERE job_id = (SELECT job_id FROM timetable.job WHERE jobname = 'execute-func');
  

  重点确认：schedule是不是@every 2 minutes，command是不是SELECT public.update_condition_after_delay()，enabled字段是不是true。

• 手动测试自定义函数是否正常工作
  任务跑不起来可能是函数本身出问题了，先手动执行函数排查：

  SELECT public.update_condition_after_delay();
  

  如果执行报错，比如权限不足、表不存在（注意schema是shopping），那得先修复函数的问题——比如给运行pg_timetable的数据库用户授权：

  -- 假设pg_timetable用pg_timetable_user用户运行
  GRANT EXECUTE ON FUNCTION public.update_condition_after_delay() TO pg_timetable_user;
  GRANT SELECT, UPDATE(condition) ON shopping.order_item TO pg_timetable_user;
  

• 查看pg_timetable的运行日志
  日志是排查问题的关键，里面会记录任务执行的详细情况——比如有没有尝试执行、执行时的错误信息（连接失败、函数报错、权限问题等）。日志文件通常在PostgreSQL的数据目录下，或者pg_timetable的安装目录里，也可以通过服务配置找到路径。重点找和execute-func相关的条目，看有没有报错提示。

• 检查时区设置是否一致
  要是数据库时区和pg_timetable的时区不一样，可能会导致调度时间计算错误。执行SHOW timezone;查看PostgreSQL的时区，再检查pg_timetable配置文件里的时区设置，确保两者保持一致。

按照这个顺序排查，应该能很快找到问题所在～

备注：内容来源于stack exchange，提问作者Minh Bùi Nguyễn