主要观点：

• 在 Recall.ai 的工作负载中，每月记录数百万小时会议，产生大量数据并写入 Postgres 数据库，并发写入导致 Postgres 停滞。
• 发现 Postgres 的 LISTEN/NOTIFY 功能在并发写入时会导致全局锁，严重影响数据库性能和可用性。
• 通过负载测试证实了全局数据库锁是导致问题的原因，消除 LISTEN/NOTIFY 后数据库性能显著提升。
• 决定在应用层跟踪相关逻辑，迁移 away from LISTEN/NOTIFY，此后 Postgres 运行平稳。

关键信息：

• 2025 年 3 月 19 日至 22 日核心 Postgres 数据库出现三次停机，症状为数据库负载和活动等待会话大幅上升、查询吞吐量大幅下降、CPU、磁盘 I/O 和网络流量骤降。
• 发现事务中发出 NOTIFY 查询时，在事务提交阶段会获取整个数据库的全局锁，序列化所有提交，导致大量负载和停机。
• 负载测试表明有 NOTIFY 时数据库 CPU 和 I/O 负载骤降，无 NOTIFY 时数据库能充分利用所有分配的 CPU 核心。
• 已迁移 away from LISTEN/NOTIFY，Postgres 运行良好，且 Recall.ai 正在招聘工程师。

重要细节：

• 在 postgres 源代码中，在 COMMIT 查询时如果事务之前发出了 NOTIFY 就会获取全局锁，该锁是对整个数据库或实例内所有数据库的全局锁，确保通知在事务提交后发送，防止未提交事务阻塞通知发送，但在多写入场景下会导致性能问题。
• 为确认全局数据库锁是问题原因，进行了带和不带 LISTEN/NOTIFY 代码的负载测试，结果证实了假设。
• 迁移 away from LISTEN/NOTIFY 仅花费一天时间，此后 Postgres 运行平稳。