Psycopg数据库连接挂起问题分析与解决

问题背景

在使用Psycopg 3.1.18版本与PostgreSQL数据库交互时，开发团队遇到了数据库连接挂起的问题。具体表现为查询长时间处于"idle in transaction"状态，导致其他访问相同数据行的操作被阻塞并最终超时。

环境配置

出现问题的技术栈包括：

• Python 3.11
• Django 4.2.9
• Gevent 24.2.1
• Psycopg 3.1.18（纯Python和二进制版本均出现此问题）
• Gunicorn 21.2.0

问题现象

通过监控PostgreSQL的活动会话，可以观察到以下异常情况：

SELECT * FROM pg_stat_activity where state = 'idle in transaction' ORDER BY query_start;

这些挂起的连接会导致事务锁持续占用，进而阻塞其他需要访问相同数据行的操作，最终引发超时错误。

初步诊断

使用strace工具追踪时，发现进程陷入了epoll_wait和fchmod调用的循环中，这表明可能存在某种死锁情况。值得注意的是，被追踪的PID实际上并不存在，这暗示了进程状态可能出现了异常。

深入分析

根据PostgreSQL的pg_locks表分析，虽然能看到锁的存在，但所有锁的状态都是granted=true，这意味着锁已经被成功获取，但事务没有被正常结束。这表明问题可能出现在应用程序处理查询结果和提交事务之间的环节。

可能的原因

1. Gevent兼容性问题：Psycopg 3.1.4到3.1.14版本与Gevent的并发模型存在已知的兼容性问题
2. Python版本问题：Python 3.11在某些情况下可能与异步库存在兼容性问题
3. 底层系统依赖：基础操作系统环境可能存在不兼容的库版本

解决方案

经过多次测试和验证，最终通过以下变更解决了问题：

1. 将基础Docker镜像从Python 3.11-buster升级到Python 3.12-bookworm
2. 确保所有相关库更新到最新稳定版本
3. 对应用程序添加更完善的日志记录，特别是在以下关键点：
   • 查询执行前
   • 查询结果返回后
   • 事务结束前

经验总结

1. 数据库连接问题往往需要从多个层面进行排查，包括客户端库、编程语言运行时和操作系统环境
2. 在异步环境下使用数据库连接池时，要特别注意版本兼容性
3. 完善的日志记录是诊断此类问题的关键工具
4. 保持基础环境更新到最新稳定版本可以避免许多潜在问题

通过这次问题解决过程，团队不仅解决了当前的连接挂起问题，还建立了更完善的数据库连接监控机制，为未来的性能优化和问题诊断打下了良好基础。