在使用PostgreSQL进行数据复制时，备机（从服务器）查询时可能会遇到报错，其中一个常见的错误是"conflict with recovery"，本文将详细解释该错误产生的原因及解决办法。
我们需要了解PostgreSQL的数据复制原理，在PostgreSQL中，数据复制是通过WAL（WriteAhead Logging）日志实现的，主服务器在处理写操作时，会将这些操作记录到WAL日志中，备机通过读取WAL日志，并将这些操作应用到自己的数据库中，从而实现数据同步。
当备机尝试读取正在被主服务器修改的数据时，就可能产生"conflict with recovery"错误，这是因为在热备模式下，PostgreSQL默认行为是：来自主服务器的任何新更改都会在等待一段较短的时间（默认为30秒）后终止使用相同数据的所有其他查询。
以下为详细解释和解决办法：
错误原因：
1、在热备模式下，备机上的查询可能会访问到已经被主服务器更改的数据版本。
2、PostgreSQL默认配置会在一定时间后终止与主服务器发生冲突的查询。
解决办法：
1、升级PostgreSQL版本： 在较新版本的PostgreSQL中，可以启用参数hot_standby_feedback，该参数允许备机通知主服务器关于备机当前查询的信息，从而减少冲突发生的可能性。
“`sql
ALTER SYSTEM SET hot_standby_feedback = on;
“`
2、调整WAL日志相关参数： 在旧版本的PostgreSQL中，可以尝试增加以下两个参数的值：
max_standby_archive_delay：设置备机在归档WAL日志时，可以延迟的最大时间。
max_standby_streaming_delay：设置备机在流式复制WAL日志时，可以延迟的最大时间。
在postgresql.conf文件中设置这两个参数的值：
“`sql
max_standby_archive_delay = 30s
max_standby_streaming_delay = 30s
“`
3、调整查询重试策略： 如果无法更改PostgreSQL配置，可以在应用层实现查询重试机制，将复制作业的重试计数设置为大于1，并设置适当的延迟，这样，在发生冲突时，作业会自动重试，可能在某次重试时成功。
“`sql
设置重试次数和延迟时间
SET max_retries = 5;
SET retry_delay = 5s;
“`
4、避免在备机上执行可能导致冲突的查询： 如果业务场景允许，尽量避免在备机上执行与主服务器发生冲突的查询，可以限制备机上的查询只读取不涉及主服务器写操作的表。
5、检查磁盘空间： 如果备机因为磁盘空间不足导致无法正常读取WAL日志，也会出现查询报错，请确保备机的磁盘空间足够。
“`bash
df h
“`
6、检查备机数据目录权限： 确保备机的数据目录权限正确，如果启动PostgreSQL的用户不是数据目录的拥有者，可能导致查询失败。
“`bash
chown R postgres:postgres /path/to/data_directory
“`
在处理PostgreSQL备机查询报错时，我们需要从多个方面进行分析和解决，通过调整配置参数、查询重试机制和磁盘空间检查等方法，可以有效地解决"conflict with recovery"错误，在实际生产环境中，我们需要根据具体场景和业务需求，选择合适的解决方案。
