PostgreSQL KnowDB 空闲后复用失效连接导致 connection closed
问题现象
OML 使用 PostgreSQL KnowDB provider 做数据库富化时，进程启动后首次查询通常成功；空闲一段时间后，相同数据再次触发富化会出现：
postgres query_named_fields failed: connection closed
同一批事件中的多条 SQL 可能连续失败，但整体流程仍打印 oml proc suc，导致事件继续下发，数据库富化字段为空或缺失。
根因判断
当前依赖的 wp-knowledge 0.11.4 PostgreSQL provider 启动时一次性创建多个 tokio_postgres::Client，之后通过 round-robin 长期复用。
当 PostgreSQL 服务端、LB、NAT 或防火墙在空闲后关闭连接时，provider 仍会继续复用已经失效的 client。当前实现没有：
- 查询前检查 Client::is_closed()
- 连接失效后的剔除与重建
- connection closed 后的重试逻辑
- 后台 connection task 退出后的状态感知
因此会在空闲后稳定出现 connection closed。
期望修复
建议 PostgreSQL provider 增加失效连接恢复能力：
- 查询前检测 client 是否已关闭
- 查询遇到 connection closed 时重建连接
- 对当前 SQL 至少重试一次
- 或改用成熟连接池替代当前 Vec<Arc> 手工池实现
临时规避
- 调整 cache.ttl_ms 无法解决，该参数只是查询结果缓存 TTL
- 可通过外部定时轻量查询降低复现概率
- 重启进程可临时恢复，但空闲后仍可能再次出现
PostgreSQL KnowDB 空闲后复用失效连接导致
connection closed问题现象
OML 使用 PostgreSQL KnowDB provider 做数据库富化时，进程启动后首次查询通常成功；空闲一段时间后，相同数据再次触发富化会出现：
同一批事件中的多条 SQL 可能连续失败，但整体流程仍打印 oml proc suc，导致事件继续下发，数据库富化字段为空或缺失。
根因判断
当前依赖的 wp-knowledge 0.11.4 PostgreSQL provider 启动时一次性创建多个 tokio_postgres::Client，之后通过 round-robin 长期复用。
当 PostgreSQL 服务端、LB、NAT 或防火墙在空闲后关闭连接时，provider 仍会继续复用已经失效的 client。当前实现没有：
因此会在空闲后稳定出现 connection closed。
期望修复
建议 PostgreSQL provider 增加失效连接恢复能力：
临时规避