PostgreSQL只读副本并行负载调优：查询被取消问题求助

核心解决方案 #

针对你的场景（负载仅需任务启动时间点之前的数据），最直接的解决方式是固定查询的快照时间，避免后续WAL变更触发冲突：

• 任务启动时，在只读副本上执行以下命令导出当前快照：

  SELECT pg_export_snapshot();
  

  记录返回的快照ID（类似00000003-0000001B-1格式的字符串）。
• 所有并行查询的事务统一使用这个快照：

  START TRANSACTION WITH SNAPSHOT '快照ID';
  -- 执行你的查询语句
  COMMIT;
  

  或者在现有事务中直接设置：

  SET transaction_snapshot = '快照ID';
  

另外，检查TimescaleDB的数据保留策略：如果主库配置了DROP CHUNK的自动清理规则，这类操作会生成WAL同步到副本，副本应用时需要删除对应chunk的数据，这是触发冲突的常见原因（即使你认为主库没有更新/删除操作）。调整保留策略的执行时间，避开负载运行的1小时窗口，或者确保保留的时间范围覆盖任务需要的数据。

问题原因分析 #

你遇到的canceling statement due to conflict with recovery错误，本质是副本在应用主库的WAL时，需要清理某些行版本，但副本上的查询事务持有包含这些行版本的快照，导致冲突。

即使你设置了max_standby_streaming_delay和max_standby_archive_delay为5分钟，且单个查询/事务耗时很短，但你的负载持续1小时，期间不断有新的查询启动，每个新查询的快照都是当前时间点的。当副本收到主库的WAL（比如TimescaleDB自动删除chunk的操作）需要清理旧数据时，只要有查询的快照包含这些要被清理的数据，超过延迟时间后就会被取消。

对疑问的回应 #

1. 不需要让应用代码等待WAL变更：等待会违背你卸载只读负载、保障主库性能的核心目标，反而会导致副本延迟增加。
2. 你可能遗漏了TimescaleDB的特性：TimescaleDB的 hypertables 自动清理（DROP CHUNK）是隐形的写操作，会生成WAL并触发副本的recovery冲突，这是很多用户忽略的点，并非普通表的VACUUM操作。
3. 关于hot_standby_feedback的判断是对的：启用该参数会让副本反馈快照信息给主库，阻止主库清理旧行版本，可能导致主库磁盘占用激增，不符合你卸载负载的初衷。

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