PostgreSQL从快照恢复后耗时查询重复问题咨询

第一步：确认查询真实执行状态 #

首先排除pg_stat_activity统计视图本身的展示异常，避免误判为客户端主动发起重复请求：

• 多次执行以下语句，观察重复条目的PID是否固定、运行时长是否持续累加：

  SELECT pid, state, query, wait_event_type, wait_event, now() - query_start AS duration 
  FROM pg_stat_activity 
  WHERE state = 'active' AND query NOT LIKE '%pg_stat_activity%';
  

• 若开启了log_statement全语句日志，直接拉取PG运行日志比对，确认相同查询是否真的被多次发起
• 对疑似异常的查询PID抓栈确认运行状态：gdb -p <目标PID> -ex "bt" -batch

第二步：排查快照恢复导致的配置异常 #

从快照恢复实例经常会出现配置残留、参数错误问题，可按以下维度排查：

• 检查连接池配置：如果实例前端部署了pgBouncer、pgpool等连接池组件，确认恢复后连接池的pool_mode配置是否正确、健康检查逻辑是否异常，连接复用失效会反复拉起相同查询
• 检查max_prepared_transactions相关状态：如果业务使用了分布式事务，快照恢复后可能残留未提交的预备事务，触发查询重复执行
• 检查实例恢复配置：如果原实例是主从架构的从节点，恢复后要确认recovery.conf（或12+版本的recovery.signal/standby.signal）是否已清理，避免实例进入异常只读/同步状态，触发上层应用自动重试

第三步：排查客户端重试逻辑 #

即使是PowerBI这类工具也可能被动触发重复查询：

• 检查客户端超时配置：快照恢复后如果磁盘IO性能下降、查询耗时超过客户端超时阈值，客户端会自动重试相同查询，出现多条一致的活跃查询条目
• 检查PowerBI数据源配置：确认是否开启了并行加载、分区加载，这类配置本身就会发起多个结构一致的查询拉取不同范围的数据，属于正常逻辑
• 对客户端地址抓包确认请求来源：tcpdump -i any port 5432 and host <对应客户端IP>，确认是否真的从对应地址发起了多次相同查询

第四步：异常处理方案 #

如果确认是异常重复查询，可按优先级处理：

• 先终止异常查询释放资源：

  SELECT pg_terminate_backend(pid) 
  FROM pg_stat_activity 
  WHERE <匹配异常查询的过滤条件>;
  

• 若为连接池配置异常，直接重启连接池组件，清空所有存量连接
• 若为客户端超时重试导致，可对应调整客户端超时阈值，或优化慢查询执行效率，避免耗时超过重试阈值
• 若确认为pg_stat_activity视图统计异常，可执行SELECT pg_stat_clear_snapshot();清理统计缓存，或重启实例重置统计信息

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