背景
昨天遇到客户现场的一个有关复制冲突的问题
备库报错：ERROR: canceling statement due to conflict with recovery，user was holding a relation lock for too long
现场情景是备库执行逻辑备份过程中出现的报错，逻辑备份相当于备库查询语句，snapshot，这时主库业务繁忙，对备库查询对象加上exclusiveAccess锁，相关wal日志传输到备库和备库的查询或逻辑复制产生冲突。
查看pg_stat_database_conflicts视图，冲突类型为cflict_lock，也就是锁冲突。
备库基于参数max_standby_streaming_delay和max_standby _archive_delay的值来解决复制冲突。max_standby_streaming_delay参数确定备库在取消与即将应用的WAL日志冲突的查询之前必须等待多长时间。如果冲突语句在这段时间后仍在运行，那么数据库会取消该语句并发出以下错误消息：
ERROR: canceling statement due to conflict with recovery
然而，此错误信息通常因为备库运行长时间的查询导致。
示例
主库执行DROP，请该语句存储在WAL文件中，稍后会在备库上应用，以保持一致性。一个SELECT语句已经在备库上运行，其运行时间大于max_standby_streaming_delay中的值，然后SELECT语句被取消，以便可以应用wal日志中的DROP语句。
注意备库查询的表要足够大，时间足够长，才可以有时间模拟出冲突的出现
备库运行长查询：
select count(*) from t5;
备库查询运行结束前，在主库操作：
drop table t5;
这时在备库收到如下报错：
ERROR: canceling statement due to conflict with recovery
DETAIL: User was holding a relation lock for too long.
STATEMENT: select * from t5;
此外，当备库上的事务正在读取主库上删除的元组时，可能会发生查询冲突。删除元组，然后在主库上触发autovacuum，会导致与仍在备库上运行的SELECT查询发生冲突；在这种情况下，对备库上的SELECT查询将终止，并显示以下错误消息：
ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
这种情况可以设置hot_standby_feedback=on 规避
解决方案
在备库上设置参数max_standby_streaming_delay max_standby_archive_delay 可以使用这些参数来留出更多查询时间，超时后再取消与即将应用的WAL日志冲突的备库的查询语句。这些参数表示从主实例接收到数据后，允许应用WAL日志的总时间。这些参数的指定取决于WAL日志的读取位置，如果从流复制中读取WAL数据，则使用max_standby_streaming_delay参数；如果WAL日志是从存储中的归档位置读取的，则使用max_standby_archive_delay参数。
设置这些参数时，请记住以下几点：
1.如果将这些参数的值设置为-1，则允许备库永远等待冲突查询完成，但是增加复制延迟，意味着备库查询到的数据可能不是最新的。
2.如果将这些参数的值设置为0，则备库的冲突查询将被取消，WAL日志条目将应用于备库。
3.参数的默认值设置为30秒，（如果没有指定单位，则默认毫秒）意味着备库查询等待30s。
根据现场环境调整这些参数的值，以平衡查询取消和复制延迟。
注意：如果要增加max_standby_archive_delay以避免取消与应用WAL日志冲突的查询，那么也考虑增加max_standby_streaming_delay。
如果看到如下错误：
"canceling statement due to conflict with recover" with "DETAIL: User query might have needed to see row versions that must be removed"
这时设置hot_standby_feedback参数，如果激活此参数，如果备库进行长查询，则会从备库发送反馈消息给主库，其中包含最旧活动事务的信息；因此，主库做update操作，同时要保留备库正常查询的这些垃圾版本。（与vacuum_defer_cleanup_age效果类似）
代价1，主库膨胀，因为垃圾版本延迟回收。
代价2，重复扫描垃圾版本，重复耗费垃圾回收进程占用CPU资源。（n_dead_tup会一直处于超过垃圾回收阈值状态，从而autovacuum不断唤醒worker进行回收动作，做无用功）
当主库的 autovacuum_naptime很小，同时autovacuum_vacuum_scale_factor很小时，尤为明显。
代价3，如果期间发生大量垃圾，垃圾版本可能会在事务完成后，集中爆炸性的被回收，产生大量的WAL日志，从而造成WAL写的IO高峰。
你还可以检查备库上的pg_stat_database_conflicts视图，获得由于与备库上恢复冲突而取消的语句的统计信息。
注意：此视图并不显示所有已发生的复制冲突，它只显示导致备库上的查询被取消的那些复制冲突信息。
总结
复制冲突类型有多种，此次介绍的冲突种类为锁复制冲突。
解决wal日志无法apply有两个策略：
- 备库告诉主库它的查询需要哪些版本，让主库保留，备库查询始终能拿到需要的版本。实际不阻塞apply wal日志，可以设置参数hot_standby_feedback。
- 备库wal日志apply进入等待，直到备库冲突查询结束，继续apply，可以设置参数max_standby_streaming_delay。
这两个参数原理近似，区别是hot_standby_feedback可以保证备库总能实现长查询不产生冲突，他主要解决快照冲突类型，而不是锁冲突类型；而max_standby_streaming_delay这个参数设置时间短于备库查询时间，超过此参数时间后，查询被取消，所以这个延迟wal日志参数设置多久需要根据实际场景设置。