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