逻辑复制从拷贝发布者数据库上的数据库快照开始。拷贝一旦完成，发布者上的更改会在它们发生时实时传送给订阅者。订阅者按照数据在发布者上被提交的顺序应用数据，这样任意单一订阅中的发布的事务一致性才能得到保证。
逻辑复制的架构类似于物理流复制（参见第 27.2.5 节）。
它由“walsender”和“apply”进程实现。
walsender进程开始逻辑解码（在第 49 章中描述）WAL并加载标准逻辑解码输出插件（pgoutput）。
插件将从WAL读取的更改转换为逻辑复制协议（参见第 55.5 节）并根据发布规范过滤数据。
然后使用流复制协议连续传输数据到应用工作者，应用工作者将数据映射到本地表并按正确的事务顺序应用接收到的各个更改。
在订阅者数据库上应用过程始终以
session_replication_role设置为replica运行。
这意味着，默认情况下，触发器和规则不会在订阅者上触发。用户可以选择使用ALTER TABLE
命令和ENABLE TRIGGER和ENABLE RULE子句在表上启用触发器和规则。
逻辑复制应用进程当前仅会引发行触发器，而不会引发语句触发器。不过，初始的表同步是以类似一个COPY命令的方式实现的，因此会引发INSERT的行触发器和语句触发器。
获取现有订阅表中初始数据的快照并且以一种特殊类型的应用进程的并行实例进行拷贝。这种进程将创建自己的复制槽并且拷贝现有的数据。复制完成后，表内容对其他后端可见。一旦现有的数据被拷贝完，worker进程会进入到同步模式，主应用进程会流式更新在使用标准逻辑复制拷贝初始数据期间发生的任意改变，这会确保表变为已同步的状态。在此同步阶段，应用和提交更改的顺序与它们在发布者发生的顺序相同。一旦同步完成，该表的复制的控制权会被交回给主应用进程，其中复制会照常继续。
发布publish参数仅影响哪些DML操作将被复制。初始数据同步在复制现有表数据时不考虑此参数。