逻辑复制冲突通常发生在订阅端apply进程尝试重放发布端的事务时。发布端执行了一条更新或删除操作，但订阅端对应的行不存在；或者发布端插入的数据在订阅端已经存在，触发了唯一约束冲突。这些冲突不会让复制槽直接断开，而是会让apply进程不断报错并重试。排查这类问题时，数据库日志是最直接的切入点。
PostgreSQL不会为逻辑复制冲突单独创建一个专用文件，所有信息都写入数据库服务日志。日志文件的位置由data_directory、log_directory等参数决定，常见默认路径在数据目录下的log子目录中。在查看日志之前，需要确认日志采集级别是否足够。默认的log_min_messages为warning，而冲突错误一般会以ERROR级别输出，因此通常能够被记录。但如果希望看到apply进程的更多上下文，比如正在处理的表名、LSN位置、具体SQL语句，则需要将log_min_messages调整为log或debug1。
此外，某些冲突信息也可能不会立即写入日志。逻辑复制的apply进程在工作时会缓冲一些状态，只有当错误反复出现或达到一定阈值时才输出。因此如果日志文件中看不到冲突记录，可以先检查pg_stat_subscription视图，确认是否存在最近错误。
一、冲突日志的产生机制
逻辑复制的冲突由apply进程触发。apply进程从订阅端复制槽读取发布端产生的WAL，将其解码为逻辑变更，然后在订阅端执行对应的SQL。当执行的SQL无法满足约束条件时，就会产生冲突。常见的冲突类型包括：唯一键或主键冲突，即插入的行在订阅端已经存在；更新或删除未命中目标行，即发布端修改的行在订阅端不存在；以及字段类型不匹配，比如发布端字段为integer，订阅端字段为text，隐式转换失败。
apply进程遇到冲突后并不会主动停止订阅，而是会记录错误并尝试继续。但在默认配置下，出错的事务会阻塞后续事务的应用，因为逻辑复制需要保持事务顺序。如果冲突迟迟不能解决，pg_stat_subscription中的latest_end_lsn会停滞，received_lsn与latest_end_lsn的差值会不断增大，表现为复制延迟。此时日志中通常会出现类似“logical replication worker”或“apply worker”的错误记录。
日志中记录的错误信息一般包含冲突类型和事务LSN。LSN是定位冲突事务的关键信息，可以通过它跳过对应事务或追溯WAL内容。例如一段常见的日志内容为：apply worker: ERROR: duplicate key value violates unique constraint "idx_users_email"，其中duplicate key表明是唯一键冲突。
二、定位日志与调整参数
要查看逻辑复制冲突日志，首先需要知道日志文件的位置。在psql中执行以下语句可以获取相关配置：
SHOW data_directory; SHOW log_directory; SHOW log_filename; SHOW log_min_messages;
data_directory表示数据目录，log_directory表示日志目录。如果log_directory的值是相对路径，则相对于data_directory。例如data_directory为/var/lib/postgresql/14/main，log_directory为log，那么实际日志路径就是/var/lib/postgresql/14/main/log。log_filename决定了日志文件的命名方式，通常包含日期或星期信息。
如果日志中没有冲突信息，可以适当降低log_min_messages级别。该参数控制写入服务日志的最低消息级别，可选值从低到高为debug5、debug4、debug3、debug2、debug1、log、notice、warning、error。默认的warning会记录error级别及以上的消息，冲突通常以error级别出现，因此默认就能记录。但如果希望看到apply进程执行的具体SQL语句，则需要设置为log或debug1。修改方式如下：
ALTER SYSTEM SET log_min_messages = 'log'; SELECT pg_reload_conf();
设置后不需要重启数据库，reload即可生效。不过log级别会记录大量普通SQL执行信息，在繁忙的生产环境中可能导致日志体积快速膨胀，建议在排查问题时临时开启，解决后恢复为warning。
三、通过系统视图和SQL排查冲突
在日志之外，PostgreSQL提供了多个系统视图用于查看逻辑复制状态。最常用的是pg_stat_subscription，它记录了每个订阅的连接信息、LSN位置以及最近一次错误。执行以下SQL可以查看冲突的简要信息：
SELECT subname,
received_lsn,
latest_end_lsn,
last_error,
last_error_time
FROM pg_stat_subscription;
其中last_error字段保存了apply进程最近一次失败的错误文本。如果该字段不为空，说明目前正存在冲突或最近发生过冲突。received_lsn表示已从发布端接收到的LSN位置，latest_end_lsn表示已经成功应用到订阅端的最新LSN位置。两者之间的差值越大，说明阻塞越严重。
另一个有用的视图是pg_replication_origin_status，它展示复制源的状态信息，有助于确认复制是否正常运行：
SELECT * FROM pg_replication_origin_status;
如果使用了复制源，还可以结合pg_replication_slots查看复制槽的活跃状态和重启LSN：
SELECT slot_name,
plugin,
active,
restart_lsn,
confirmed_flush_lsn
FROM pg_replication_slots
WHERE slot_type = 'logical';
当confirmed_flush_lsn长时间小于当前WAL写入位置时，说明订阅端没有确认消费完已发送的逻辑变更，可能存在冲突或性能瓶颈。这些视图与日志配合使用，能够快速定位冲突发生在哪张表、哪个事务以及对应的LSN。
四、冲突处理与临时跳过方法
确认冲突后，首先要分析冲突原因。如果订阅端数据被手工修改过，导致与发布端不一致，通常需要修复订阅端数据。例如订阅端某张表被删除了行，而发布端随后更新了这些行，就会产生更新未命中冲突。此时需要根据业务逻辑补删或重建对应行，使数据一致性恢复。
对于短期内无法通过修改数据解决的冲突，可以使用ALTER SUBSCRIPTION跳过对应事务。跳过操作需要知道冲突事务的LSN。这个LSN可以从日志中的错误信息获取，也可以根据pg_stat_subscription中的latest_end_lsn推断出一个后续LSN。跳过语法如下：
ALTER SUBSCRIPTION your_subscription_name SKIP (lsn = '0/16C8A18');
执行后订阅端会跳过该LSN对应的事务，apply进程继续处理后续事务。需要注意的是，跳过事务会导致该事务的变更不会应用到订阅端，可能造成数据不一致。跳过之后应当尽快修复数据或重新同步相关表。继续观察pg_stat_subscription，如果last_error清空，说明冲突已经解决。
如果冲突频繁出现，建议检查订阅端和发布端的表结构是否完全一致，特别是约束、触发器和字段类型。触发器在订阅端执行时也可能引发冲突，可以通过在订阅端禁用触发器或使用DISABLE TRIGGER ALL来避免。此外，发布端和订阅端都应当避免手工修改复制表数据，最好通过逻辑复制本身来保持同步。
PostgreSQL逻辑复制冲突日志复制槽修改时间：2026-09-26 07:33:06