PostgreSQL QueryExecutor查询完成后仍在receiveChar()处无限挂起

问题根因 #

该问题本质是长查询执行过程中网络中间设备静默断开TCP连接，客户端未感知到断连事件导致的无限阻塞，符合小数据量正常、大数据量必现的特征，具体触发逻辑如下：

• 200万条数据的INSERT ... SELECT执行时间较长，执行过程中TCP连接上无任何数据包交互
• 路径上的防火墙、负载均衡、云数据库网关等中间设备会主动断开长时间无流量的TCP连接，且断连时未向两端发送FIN/RST包
• PostgreSQL服务端执行完查询后向客户端发送的响应包被中间设备丢弃，客户端永远收不到结束标识
• pgjdbc默认未配置socket超时，会一直阻塞在receiveChar()等待服务端返回数据

解决方案 #

临时验证方案 #

调整JDBC连接参数，在连接串中新增以下配置即可避免无限阻塞：

jdbc:postgresql://<RDS地址>:<端口>/<库名>?socketTimeout=660&tcpKeepAlive=true

• socketTimeout：单位为秒，设置为比迁移任务最大预期耗时多10%即可，到达时间后会主动抛出SocketTimeoutException，避免无限等待
• tcpKeepAlive：开启TCP保活探测，主动向服务端发送心跳包避免中间设备判定连接闲置

最优生产方案 #

针对大数据量迁移场景，建议拆分任务避免单条SQL执行时间过长：

• 按主键、时间等维度拆分迁移范围，每次只迁移1-10万条数据
• 分批执行SQL并提交事务，单批次执行时间控制在1分钟以内
• 迁移过程中记录断点，出现异常后可从断点继续执行无需重头开始

额外排查建议 #

如果调整参数后仍出现问题，可通过以下路径验证：

• 检查云RDS的空闲连接超时配置，确认阈值大于最长单SQL执行时间
• 抓包验证客户端与服务端之间的TCP连接状态，确认是否存在中间设备丢包
• 确认操作系统层面的TCP保活参数，将默认的2小时探测间隔调整为30秒，适配中间设备的超时规则

内容的提问来源于stack exchange，提问作者I was in the neighborhood