我正在测试2个PostgreSQL 11数据库之间的逻辑复制以用于我们的生产（由于这个答案，我能够设置它-PostgreSQL logical replication - create subscription hangs），并且运行良好。
现在，我正在测试将在生产数据库上自动设置脚本和过程的脚本，但是我遇到了逻辑复制槽的奇怪问题。
由于必须重新启动设置中的某些更改，我不得不重新启动逻辑副本-当然，将来也可能在副本上发生这种情况。但是主服务器上的逻辑复制插槽并未断开连接，并且对于某些PID仍然处于活动状态。
我放弃了对主服务器的订阅（我仍在测试），并尝试使用新的逻辑复制插槽重复整个过程，但是我遇到了奇怪的情况。
我无法使用新名称创建新的逻辑复制插槽。在旧的逻辑复制插槽上运行的进程仍处于活动状态，并显示wait_event_type=Lock和wait_event=transaction。
当我尝试使用pg_create_logical_replication_slot创建新的逻辑复制插槽时，会遇到类似的情况。创建了新的插槽-我在pg_catalog中看到了它，但是对于发出此命令的会话的PID，它被标记为活动的，并且该命令无限期挂起。当我检查进程时，可以看到此命令处于活动状态，并且具有相同的等待值Lock / transaction。
我试图激活postgresql.conf中的参数“ lock_timeout”并重新加载配置，但没有帮助。
保留该旧的挂起过程很可能会使整个postgres崩溃，因为它是“投稿者”过程。在进程列表中仍可以看到副本的IP，状态为“空闲”。
我试图找到一些可以帮助我迫使postgres停止该walsender的参数。但是设置wal_keep_segments或wal_sender_timeout并没有改变。我什至试图停止复制更长的时间-没有效果。
是否有某种方法可以在不重新启动整个postgres的情况下执行此操作？像强制walsender超时或锁定事务等...
因为如果这样的事情在生产中发生，我将无法使用重启或任何其他“蛮力”。谢谢...
更新： “ Walender”进程在一段时间后“消失”，但日志未显示任何相关信息，因此我不知道它何时确切发生。我只能猜测它取决于tcp_keepalives_ *参数。 Debian 9的默认设置是2小时以保持空闲状态。因此，我尝试在postgresql.conf中设置这些参数，并将在以下测试中看到。
答案 0 :(得分：0)
今天足够奇怪的是，一切正常，没有任何问题，无论我如何尝试模拟昨天的问题，我都无法解决。也许所涉及的云数据中心中存在一些网络通信问题-我们在连接到其他数据库时也偶尔会超时。
所以我真的不知道答案，除了“等到主模上的walender过程之后”，这很可能受tcp_keepalives_ *设置的影响。因此，我建议在postgresql.conf中将它们设置为一些合理的值，因为OS上的默认值通常太大。
实际上，由于类似的问题，我们将其用于大型分析数据库（在PostgreSQL和OS上均已设置）。有时会计算统计信息的Golang和nodejs程序无法识别数据库会话在某些情况下已结束或消失，并且一直挂起，直到OS在2小时后终止连接为止（默认为Debian）。所有这些似乎总是与网络通信问题有关。正确设置tcp_keepalives_ *可以在出现问题时更快地进行反应。
旧的walender进程在master上死后，您可以重复所有步骤，并且应该可以运行。看来我昨天运气不好...