Postgres逻辑复制：是否需先创建Publication再创建Replication Slot？

这是已知行为吗？ #

这是PostgreSQL的已知行为。

原因详解 #

逻辑复制槽会从创建时刻开始记录所有事务的LSN（日志序列号）。如果在复制槽创建后、发布（Publication）创建前执行了数据库操作，这些操作的事务日志会被槽保留。当你尝试用这个槽关联发布启动复制时，复制进程会从槽的起始LSN开始回放事务，但在那些早于发布创建时间的事务中，发布还未被系统注册，pgoutput插件无法找到对应的发布规则，因此抛出publication "test_pub" does not exist的错误——这个报错确实有误导性，容易让用户误以为发布真的不存在，而非LSN时序不匹配导致的问题。

解决办法 #

有两种可靠的解决方式：

1. 遵循标准流程：先创建发布，再创建复制槽
   这是符合逻辑复制设计预期的顺序，确保复制槽的起始LSN晚于发布创建时间，所有被槽记录的事务都能对应到已存在的发布：

   -- 先创建发布
   create publication test_pub for table mytable;
   -- 再创建复制槽
   select pg_create_logical_replication_slot('test_slot', 'pgoutput');
   

2. 若已先建槽，删除旧槽后重新创建
   如果因特殊情况必须先创建槽，最稳妥的方式是删除旧槽，待发布创建完成后再新建槽，确保槽的起始LSN在发布创建之后：

   -- 删除已存在的旧槽
   select pg_drop_replication_slot('test_slot');
   -- 创建发布
   create publication test_pub for table mytable;
   -- 新建关联该发布的复制槽
   select pg_create_logical_replication_slot('test_slot', 'pgoutput');
   

关于文档与报错优化 #

PostgreSQL官方文档在逻辑复制最佳实践中提到了推荐的创建顺序，但对这种反向操作的异常场景描述不够明确。你提出的优化报错信息的建议非常合理，当前的报错提示未能准确反映问题本质。你可以考虑向PostgreSQL社区提交反馈，建议优化该场景的报错内容，帮助用户更快定位问题。

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