PostgreSQL逻辑复制：退出Copy模式后无法重启复制槽问题

你的问题核心出在临时复制槽（TEMPORARY）的生命周期特性，以及复用槽时的LSN指定逻辑上：

根本原因 #

PostgreSQL临时复制槽有一个关键特性：当使用该槽的复制会话结束（即你发送CopyDone退出COPY模式时），即使数据库连接仍保持打开，临时复制槽也会被自动删除。

你第二次执行START_REPLICATION时，原临时槽已经不存在，但由于交互逻辑的原因，服务器没有返回明确错误，而是直接返回CommandComplete，导致无法进入COPY模式。另外，你第二次启动复制时指定LSN为0/0也不合理——即使槽存在，这个LSN通常远低于复制槽当前的restart_lsn，服务器要么报错，要么不会返回任何数据。

解决办法 #

根据你的使用场景，有两种可行方案：

方案1：改用持久化复制槽 #

去掉CREATE_REPLICATION_SLOT中的TEMPORARY关键字，创建持久化复制槽：

CREATE_REPLICATION_SLOT "name" LOGICAL pgoutput (SNAPSHOT 'nothing')

持久化复制槽不会随复制会话结束而删除，只要连接存在（甚至连接断开后），槽都会保留。退出COPY模式执行查询后，再次执行START_REPLICATION时，使用复制槽当前的restart_lsn作为起始位置（可通过SELECT restart_lsn FROM pg_replication_slots WHERE slot_name = 'name'查询），就能正常进入COPY模式继续复制。

方案2：每次重启复制前重新创建临时槽 #

如果必须使用临时槽，每次回到复制模式时，都要先清理旧槽（若存在）再重新创建：

-- 删除旧槽（如果存在）
DROP_REPLICATION_SLOT "name" IF EXISTS;
-- 重新创建临时槽
CREATE_REPLICATION_SLOT "name" TEMPORARY LOGICAL pgoutput (SNAPSHOT 'nothing');
-- 启动复制
START_REPLICATION SLOT "name" LOGICAL 0/0 (
        binary 'on',
        messages 'on',
        proto_version '1',
        publication_names 'pub'
      )

这种方式适合不需要长期保留复制进度的场景，但要注意每次重启会从指定LSN开始复制，可能产生重复数据。

额外注意事项 #

• 执行START_REPLICATION时，务必使用复制槽当前的restart_lsn作为起始位置，避免重复消费WAL或触发服务器错误。
• 退出COPY模式时，确保发送CopyDone而非CopyFail，后者会导致复制槽进入错误状态，需要手动清理。

内容的提问来源于stack exchange，提问作者S.A.N