逻辑复制的架构与物理流复制（参见第 26.2.5 节）类似。
它由walsender和apply进程实现。
walsender进程启动WAL的逻辑解码（详见第 47 章）
并加载标准的逻辑解码输出插件（pgoutput）。
插件将从WAL读取的更改转换为逻辑复制协议
（参见第 54.5 节），并根据发布规范过滤数据。
然后，数据通过流复制协议持续传输到apply工作进程，
该进程将数据映射到本地表，并按照正确的事务顺序应用接收到的各个更改。
在订阅者数据库上应用过程始终以
session_replication_role设置为replica运行。
这意味着，默认情况下，触发器和规则不会在订阅者上触发。用户可以选择使用ALTER TABLE
命令和ENABLE TRIGGER和ENABLE RULE子句在表上启用触发器和规则。
逻辑复制应用进程当前仅会引发行触发器，而不会引发语句触发器。不过，初始的表同步是以类似一个COPY命令的方式实现的，因此会引发INSERT的行触发器和语句触发器。
在现有的订阅表中，初始数据被快照并 在一种特殊类型的应用进程的并行实例中复制。 这些特殊的应用进程是专门的表同步 工作进程，为每个要同步的表生成。每个表 同步进程将创建自己的复制槽并 复制现有数据。复制完成后，表 内容将对其他后端可见。一旦现有数据 被复制，工作进程进入同步模式，这确保 表通过使用标准逻辑复制流式传输在初始数据复制期间发生的任何更改而与主 应用进程保持同步状态。在此 同步阶段，更改按发生在发布者上的相同顺序应用和提交。一旦同步完成， 表的复制控制将返回给主应用 进程，复制将正常继续。
发布
publish
参数仅影响哪些DML操作将被复制。初始数据同步在复制现有表数据时
不考虑此参数。
如果表同步工作进程在复制期间失败，应用工作进程
将检测到故障并重新生成表同步工作进程以
继续同步过程。这种行为确保了
瞬时错误不会永久中断复制设置。另请参见
wal_retrieve_retry_interval。