如果我有 3 个数据库
只是为了澄清“仅用于读取”意味着我的应用程序不会尝试修改该数据库。反过来适用于“仅用于写入”。我不是在谈论数据库本身的功能。也许我会使用权限来实现这一点，但无论如何。
通过浏览逻辑复制的官方文档，我无法找到一些问题的答案：
在对 Db1 进行新写入的情况下，Db2 和 Db3 会在同步更改时都锁定，还是允许在同步的同时进行读取？
如果订阅服务器在发布对 Db1 的新更改时正在执行读取，那么可用的更改是否会在它们到达订阅者后立即执行的下一个操作，无论有多少读取已经在等待执行（如果有的话）？
我担心的是负载平衡集群（仅用于读取）PostgreSQL 服务器的一致性，这些服务器是 Db1 的副本。它们都应该与 Db1 同步，在与 Db1 发布的新更改同步之前不允许对它们进行任何新的读取。如果我不能通过逻辑复制来做到这一点，那么有什么替代方案（如果有的话）？
在对 Db1 进行新写入的情况下，Db2 和 Db3 在更新时是否都会锁定读取？
作家不会在宏观层面上阻挡读者。使用逻辑复制不会改变这一点。
在与 Db1 同步之前是否会等待完成当前读取 - 即使在多核服务器上也是如此？
从某种意义上说。如果读者有一个页面被锁定以供阅读，作者将无法写入该页面。但是，这种锁定通常保持极短（亚微秒）。
如果有等待，无论该服务器的操作队列中已经有多少读取，同步是否会成为下一个要执行的操作？
什么是“操作队列”？我不相信 PostgreSQL 有一个。
它们都应该同步，在同步到 Db1 的新更改之前不允许对它们进行任何新的读取。
即使所有查询都在同一台服务器上完成，您也无法控制只读查询是在提交其他内容之前执行一纳秒，还是之后执行一纳秒。即使使用可序列化的隔离级别，您也只能保证存在一些事务的序列顺序。您不会被告知该顺序是什么，也不允许查看诸如 clock_timestamp() 之类的东西来弄清楚。如果“只读”查询需要确保某物静止不动，则需要锁定它。
如果只读事务使用其数据视图来做出决定，则该决定需要反映回数据库，这意味着该事务并不是真正的只读事务。
如果我不能通过逻辑复制来做到这一点，那么有什么替代方案（如果有的话）？
想要一些不同的东西。即使在同一台服务器中，您也无法做到这一点。