报错：
canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
Hot Standby 环境下的 standby 节点执行查询时报错，报错信息如下：
1、执行长时间查询时报错。
根据错误信息，初步估计当在从库上执行查询时，与主库发生了冲突。
2、网上GOOGLE ，信息如下
Long running queries on the standby are a bit tricky, because they
might need to see row versions that are already removed on the master.
备注：意思是说，长时间SQL如果跑在 standby 节点上是一个笑话，因为 standby 节点有可能需要读取主库上被 removed 的数据。
3、解决方法，修改参数
根据实际情况，调大参数：max_standby_streaming_delay = 30min;
当在 Standby 提供应用时，如果 Standby 节点上的SQL 与接收主库日志发生冲突时，
这个参数决定了从库等侍这个查询的时间，默认值为 30s, 有SQL执行时间估计在二分钟左
右，从而被 Standby库主动 Cancel 了。也可以将这个参数设置成 -1. 表示 standby 节点永远等侍这个查询，
这无疑是有风险的，如果这个查询不结束，那么从库一直处于与主库的中断状态，不会同步主库数据，而会一
直等从库这个SQL执行完成。
4、其他说明
PostgreSQL 的 Hot Standby常被用来当只读的数据库提供查询或者统计服务, 但是由于各种原因查询SQL可能被cancel掉。
例如：
1）主库执行了DROP某TABLE的操作, 而standby库上某用户正在查询这个表的数据. 当standby接收到了这些XLOG的信息并且
准备在standby库上apply的时候, 如果这个SQL还在执行, 就发生冲突了, 这个时候standby 要判断是否要cancel掉这个SQL
使得apply可以正常进行下去, 或者standby选择等待多长时间.
2）主库执行删除表空间或者删除库等相关的操作也会遇到上面的问题.
3）更隐晦的是主库上执行了vacuum操作, 这些被vacuum掉的tuple, 可能是standby库上的SQL可见的TUPLE, 也会发生冲突.
4）还有其他原因
那么Standby根据什么来判断是CANCEL SQL还是选择等待, 如果等待, 等多长时间?有两个参数控制：
max_standby_archive_delay
max_standby_streaming_delay
如果值等于-1表示永不因为recovery 和SQL冲突原因cancel standby上的SQL.
如果设置了一个值如30秒, 那么在cancel 冲突的SQL前, 会等待，通过GetStandbyLimitTime来判断是否要触发CANCEL SQL, 当GetStandbyLimitTime返回的值为0 时表示永不触发CANCEL, 如果返回的是一个时间值, 这个时间值和当前时间进行比较,如果小于当前时间则进行CANCEL操作.