如何监控pg_notify发出的通知数据及送达状态？

完全可以实现pg_notify全链路通知状态的监控，通过分层校验的方式可以明确区分故障点是在PostgreSQL通知投递层，还是客户端接收/业务处理层。

• 第一层：PG内置状态校验
  pg_notify的通知只有在调用它的事务成功提交后才会进入发送队列，你可以直接查询内置统计视图判断队列运行状态：

-- 查询通知队列使用率、累计入队/投递成功计数
SELECT
  queue_usage AS "通知队列使用率",
  notifications_queued AS "累计入队通知数",
  notifications_delivered AS "累计投递成功通知数"
FROM pg_stat_notify;

如果统计到的notifications_queued数值和业务侧触发pg_notify的调用次数匹配，但notifications_delivered长期不增长、queue_usage持续接近1，说明通知在PG层出现阻塞，常见原因是默认8MB的通知队列被打满、持有通知的事务长期未提交导致消息无法出队。

• 第二层：旁路独立监听做基准对照
  部署一个无业务逻辑的轻量监听客户端，和出问题的业务客户端使用完全相同的连接权限、连接参数，对同一个channel执行LISTEN操作。业务侧触发pg_notify时，给每条通知拼接全局唯一标识（比如用事务IDpg_current_xact_id()加业务表主键生成唯一消息ID）。

  1. 这个独立监听进程只做日志记录：收到通知就把消息ID、接收时间写入独立审计日志/表，不做任何额外逻辑
  2. 对比三组数据：业务侧触发pg_notify的总次数、独立客户端收到的通知总数、业务客户端上报的收到通知总数
     • 如果独立客户端收到的通知数和PG侧触发数完全匹配，说明pg_notify本身的发送、投递逻辑完全正常，故障一定出在业务客户端的连接状态、消息消费逻辑上
     • 如果独立客户端也收不到对应缺失的通知，优先排查触发pg_notify的事务是否发生回滚——事务回滚时，该事务内触发的所有pg_notify通知会被直接丢弃，不会进入投递队列，这是最常见的“PG丢通知”误判场景

• 第三层：内核级全流程日志审计（高精度排查用）
  如果需要抓取每一条通知的完整投递轨迹，可以临时开启debug_notify参数，将客户端日志级别调整到DEBUG1，PG会在服务日志中打印每一条通知的入队时间、目标channel、payload内容、接收客户端PID、投递结果，无遗漏覆盖全流程。

注意：debug_notify开启后日志输出量会大幅提升，定位完问题后记得及时关闭参数，避免日志占满磁盘空间。

• 不要忽略半开连接影响：如果业务客户端和PG的连接出现TCP半断连（中间网络丢包、两端未感知到连接断开），PG会持续尝试向该失效连接投递通知，直到连接超时判定死亡才会清理待投递消息，这种场景下旁路独立客户端可以正常收到所有通知，能直接定位故障在业务侧连接层
• 不要在事务提交前校验通知：pg_notify不是实时发送的，事务提交前所有通知都暂存在当前事务的私有内存中，不会进入全局队列，此时查任何投递状态都没有参考意义

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