数据库架构和 DDL 命令不会被复制。可以通过使用 pg_dump --schema-only 手动复制初始架构。后续架构更改需要手动保持同步。(不过请注意，两边没有必要绝对相同的架构。）当实时数据库中的架构定义发生更改时，逻辑复制很健壮：当在发布者上更改架构，复制数据开始到达订阅者，但不适合表架构时，复制将在架构更新前出错。在许多情况下，可以通过首先将附加架构更改应用于订阅者来避免间歇性错误。

序列数据不会被复制。当然，由序列支持的序列或标识列中的数据会作为表的一部分被复制，但序列本身仍会向订阅者显示起始值。如果订阅者用作只读数据库，那么通常不会出现问题。但是，如果打算对订阅数据库进行某种切换或故障切换，则需要通过从发布者复制当前数据（可能使用 pg_dump）或通过从表本身确定足够高的值来将序列更新为最新值。

支持复制 TRUNCATE 命令，但在截断通过外键连接的一组表时必须小心。复制截断操作时，订阅者将截断在发布者上已截断且已通过 CASCADE 显式指定或隐式收集的同一组表，减去不属于订阅的一部分的表。如果所有受影响的表都属于同一订阅，则这种操作可以正常工作。但如果要在订阅者上截断某些表，且这些表具有与不属于同一订阅（或任何订阅）的表的外键链接，则在订阅者上应用截断操作会失败。

大对象（请参见 第 33 章）不会被复制。除此以外不存在其他解决方法，只能将数据存储在普通表中。

只支持复制表，包括分区表。尝试复制其他类型的关联（例如视图、物化视图或外部表）会导致错误。

进行分区表之间复制时，默认情况下，实际复制起源自发布者上的叶子分区，因此发布者上的分区也必须作为有效的目标表存在于订阅者上。（它们自己可以是叶子分区，或者可以进一步子分区，或者甚至可以是独立表。）发布还可以指定将使用分区根表的标识和架构来复制更改，而不是实际生成更改的各个叶子分区（请参见 CREATE PUBLICATION 的 publish_via_partition_root 参数）。

在已发布表上使用 REPLICA IDENTITY FULL 时，需要注意的是，如果表包含没有 B-tree 或哈希的默认运算符类的具有数据类型（例如点或框）的属性，则不能对订户应用 UPDATE 和 DELETE 操作。但是，可以通过确保表为主键或为其定义副本标识来克服此限制。