Postgres Trigger listening to a channel not responsive after some time

快速结论：这个报错通常发生在 n8n 的 Postgres Trigger 长时间监听某个 channel 后，连接被静默断开，导致 trigger 不再响应，但界面和工作流上没有任何报错。优先排查 Postgres 监听连接是否还存在于 pg_stat_activity 中，以及连接空闲后是否被中间网络设备或 Postgres 服务端回收。

适用环境：Issue 中已确认的环境为 n8n 1.80.5（Docker 自托管）、Node.js 20.18.3、数据库 Postgres、executionMode 为 scaling；另有用户报告在 n8n 1.44.1 上也出现类似问题。Issue 未提供操作系统、Python、CUDA、显卡等信息，不应据此补写。

最快修复方案：暂无确认的一步修复方案。Issue 中唯一被用户实际验证“解决了问题”的做法，是在 Postgres 服务端配置中显式调小 TCP keepalive：tcp_keepalives_idle = 300、tcp_keepalives_interval = 30、tcp_keepalives_count = 3。该方案属于可优先尝试，并非官方发布的修复。

注意事项：上述 keepalive 参数原本是 Postgres 客户端连接参数（如 keepalives_idle、keepalives_interval、keepalives_count），在服务端配置文件中写入是否对所有客户端行为生效，以及是否应改由 n8n 连接侧或后端代码默认设置，Issue 中仍在讨论，没有最终结论。该做法可能影响同一 Postgres 实例上的其他连接。

问题场景

用户在 n8n 中使用 Postgres Trigger 节点，监听某个特定 channel。工作流处于 active 状态并运行一段时间后，trigger 突然不再响应新事件。Issue 作者表示 channel 像是丢失了，或者与数据库的连接已经断开，但界面和日志中看不到明确报错。多名用户在评论中确认遇到同样现象：有的是一段时间后 trigger 完全不响应，有的是部分 channel 继续工作、部分 channel 停止工作。

报错原文

Postgres Trigger listening to a channel not responsive after some time

No error message (as far as I can see) I don't see something stating that the connection has been lost.

原因分析

Issue 评论中一位用户给出了较完整的排查结果：问题不一定完全出在 n8n 本身，而是 n8n 为 Postgres Trigger 建立的监听连接在一段空闲时间（大约 20 分钟或更久）后被中断。可能原因包括负载均衡器、路由器、Docker 网络等中间环节主动终止空闲连接，也可能是 Postgres 服务端侧的超时回收。Postgres 默认的 TCP keepalive 首次检查时间约为 2 小时，对这类场景帮助不大。连接被断开后，工作流虽然仍显示 active，但 trigger 已不再监听对应 channel，并且整个过程静默发生，只会偶尔在 Postgres 侧出现类似 “terminated by peer” 的提示。

此外，在测试模式下执行 trigger 会启动一个会话，测试结束后会执行 UNLISTEN 并终止该会话；停用再启用工作流会强制新建一个持久会话，但这个会话之后仍可能再次被中断。这些都是 Issue 中可确认的观察，不是推测性补写。

环境排查

确认 n8n 版本，Issue 中涉及 1.80.5 和 1.44.1。
确认部署方式，Issue 中为 Docker 自托管。
确认 Node.js 版本，Issue 中为 20.18.3。
确认数据库为 Postgres。
确认 executionMode 是否为 scaling，Issue 中为 scaling，concurrency 为 10。
确认 Postgres Trigger 对应 channel 的监听连接是否仍然存在，可用 Issue 中给出的查询检查：

SELECT pid,
       usename,
       datname,
       application_name,
       client_addr,
       client_port,
       state,
       wait_event,
       query,
       now() - backend_start AS uptime
FROM pg_stat_activity
WHERE datname = 'chatwoot'
    AND query ILIKE '%listen%'
ORDER BY query_start DESC;

注意：上面查询中的 datname = 'chatwoot' 是提问者自己的库名，实际使用时需要改成你自己的数据库名。

确认 n8n 与 Postgres 之间是否存在负载均衡器、代理、路由器或 Docker 网络等可能回收空闲连接的中间组件。
确认 Postgres 当前的 tcp_keepalives_idle、tcp_keepalives_interval、tcp_keepalives_count 配置值。

解决步骤

先确认故障现象：Postgres Trigger 在 active 状态下不响应，且界面无报错。可对照 Issue 中的截图，确认 trigger 状态与 channel 监听情况。
在 Postgres 侧查询 pg_stat_activity，查看是否还存在对目标 channel 执行 LISTEN 的连接。工作流正常时应当能看到对应的监听进程线程。
如果发现该监听连接已经消失，但工作流仍是 active，则基本符合 Issue 中描述的“静默断开”现象。
按照 Issue 中用户验证有效的做法，在 Postgres 配置或启动命令中加入 TCP keepalive 参数，让连接在空闲时更早发送保活包：

tcp_keepalives_idle = 300
tcp_keepalives_interval = 30
tcp_keepalives_count = 3

修改后重载或重启 Postgres 使配置生效，再停用并重新启用对应的 n8n 工作流，强制为 Postgres Trigger 新建一个持久监听会话。
如果问题依旧，可进一步排查 n8n 与 Postgres 之间的负载均衡、代理、Docker 网络等是否存在空闲连接超时或强制回收策略。Issue 中提出这些参数更适合配置在 n8n 的 Postgres 连接侧或由 n8n 后端默认设置，但该方向尚未在 Issue 中形成最终方案，只能作为后续排查方向。

验证方法

修改配置并重新启用工作流后，等待超过原先失效的时间段（Issue 中提到大约 20 分钟或更久），在 Postgres 目标 channel 上插入测试数据，观察 n8n Postgres Trigger 是否仍能正常触发工作流。同时再次执行 pg_stat_activity 查询，确认对应的 LISTEN 连接在空闲后仍然存在，没有静默消失。若两者都正常，说明 keepalive 方案在当前环境生效。