postgresql触发器不能直接执行python脚本，因事务上下文禁止外部进程调用，会导致数据不可见、超时中断、权限失败；唯一安全方案是pg_notify+listen异步解耦，触发器仅发通知，由独立python消费者监听并处理。
pg_notify + LISTEN 是唯一安全可行的路径，直接在触发器里 system()、shell_exec() 或调用 http_post() 都会破坏事务一致性。
为什么不能在触发器里直接执行Python脚本
PostgreSQL 触发器运行在事务上下文中，任何外部进程调用（比如 pg_sleep() 之外的系统调用）都面临三个硬性限制：
– 事务未提交时，新连接查不到刚插入的数据
– 外部进程启动延迟不可控，容易超时导致 query_timeout 中断整个事务
– 数据库服务账户（通常是 postgres 用户）大概率没有 Python 环境、PATH 或文件读写权限
强行用 plsh、plpythonu 或 sys_exec 不是“配置没开对”，而是设计上就拒绝这种耦合。
用 pg_notify 实现解耦式异步通知
这是 PostgreSQL 原生支持、零依赖、不阻塞事务的轻量通信机制。触发器只发通知，Python 消费者监听并处理。
操作要点：
– 在触发器函数中调用 pg_notify('queue_channel', payload_json::text)，payload 必须是字符串（建议用 row_to_json(NEW)::text）
– 不要在触发器里做 JSON 字符串拼接，避免 SQL 注入和编码问题
– 通知内容不要超过 8000 字节（PostgreSQL 限制），超长需截断或存表后传 ID
– 通知不保证送达，消费者需自行幂等处理（例如用 upsert 更新状态）
Python 消费者如何可靠监听并执行
别用轮询，用 asyncpg 的 add_listener 或 psycopg3 的 listen 接口保持长连接。
关键实践：
– 连接必须设 autocommit=True，否则 LISTEN 会报错
– 监听前先 LISTEN queue_channel，再进入 await conn.notifies.get() 循环
– 收到通知后，立即 spawn 子进程执行你的脚本：subprocess.run(['python3', '/path/to/handler.py', notify_payload], capture_output=True)
– 脚本执行失败要记录日志并重试（建议加指数退避），不要丢弃通知
– 若需反馈结果回数据库，走独立连接 INSERT 到状态表，绝不在监听连接里写数据（避免锁表）
容易被忽略的并发与重试陷阱
多个消费者实例同时监听同一 channel 时，PostgreSQL 会广播给所有 listener——这不是负载均衡，而是重复投递。这意味着：
– 每个消费者都得实现幂等逻辑（例如用 INSERT ... ON CONFLICT DO NOTHING 记录已处理 ID）
– 不要用文件锁或临时表做协调，推荐用 pg_advisory_lock 对 payload hash 加锁
– 通知丢失不可恢复，所以消费者必须能从数据库补漏（例如定期扫描 created_at > now() - '5min' 的未处理记录）
– pg_notify 不提供确认机制，别指望“收到即成功”
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
