PostgreSQL 10中WAL复制线程是否会引发主库锁问题？

核心原因：WalSender的工作机制不会触发锁竞争 #

• WalSender的核心职责是读取主库WAL日志并推送给副本，全程是只读访问WAL缓冲区和文件，不会对用户业务表、索引等对象加任何锁。
• 不管是默认的异步复制还是半同步复制，WalSender都不会阻塞主库事务提交：半同步模式下最多是等待副本确认WAL接收，但这属于事务提交阶段的等待，和锁竞争完全是两码事。
• PostgreSQL的设计逻辑里，WalSender就是为了不干扰主库业务运行，它的资源消耗主要在CPU和网络，根本不会抢占锁资源。

极端场景下的间接影响（绝非锁问题） #

虽然直接锁问题不可能，但极端情况可能有间接性能影响，容易被误判：

• 如果副本接收WAL的速度跟不上主库，会导致主库WAL文件堆积，此时主库要花更多资源做WAL清理（比如pg_xlog目录的维护），可能拖慢整体性能，但这不是锁阻塞。
• 复制槽配置不合理的话，主库会一直保留副本未确认的WAL，堆积过多会占满磁盘，进而影响主库操作，但这也和锁无关。

长时查询才是锁问题的合理根源 #

你方的判断完全符合PostgreSQL的常见问题场景：

• 长时运行的SELECT会持有ACCESS SHARE锁，直接阻塞ALTER TABLE、DROP TABLE这类DDL操作，或者导致UPDATE/DELETE的行锁升级受阻。
• 重启PostgreSQL会强制终止所有活跃会话，释放所有持有的锁，这正好解释了“重启后问题消失”的现象。

排查验证步骤 #

要彻底厘清问题，可以做这几步：

1. 查询pg_locks视图，找到锁持有者的PID，再通过pg_stat_activity查看该PID对应的会话状态和执行的SQL，确认是不是长时查询。
2. 查询pg_stat_replication视图，查看WalSender的state是否为streaming、sent_lsn和write_lsn的差距大小，确认复制有没有严重延迟。

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