数据库模式和 DDL 命令不会被复制。初始模式可以手工使用 pg_dump --schema-only 复制。之后的模式更改需要手工保持同步。（不过请注意，两端的模式其实不需要绝对一致。）当活动数据库中的模式定义发生变化时，逻辑复制仍然能够稳健运行：如果发布端修改了模式，而复制数据开始到达订阅端时与表模式不匹配，复制就会报错，直到模式被更新。在很多情况下，可以通过先在订阅端应用仅添加内容的模式变更来避免间歇性错误。

序列数据不会被复制。由序列支撑的 serial 或标识列中的数据当然会作为表的一部分被复制，但序列本身在订阅端仍会显示起始值。如果订阅端被当作只读数据库使用，这通常不是问题。但如果计划把订阅端数据库用作某种切换或故障切换目标，那么就需要把序列更新到最新值，可以从发布端复制当前数据（例如使用 pg_dump），也可以直接从表本身确定一个足够高的值。

支持复制 TRUNCATE 命令，但在截断通过外键连接在一起的一组表时必须格外小心。复制截断操作时，订阅端会截断与发布端相同的一组表，这组表可以是显式指定的，也可以是通过 CASCADE 隐式收集到的，然后再减去不属于该订阅的表。如果所有受影响的表都属于同一个订阅，这样可以正确工作。但如果订阅端上将被截断的某些表通过外键链接到了不属于同一个订阅（或根本不属于任何订阅）的表，那么在订阅端应用该截断操作就会失败。

大对象（见第 33 章）不会被复制。除了把数据存储在普通表中，没有其他变通办法。

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

在分区表之间复制时，默认情况下，实际复制来源是发布端的叶子分区，因此发布端上的这些分区也必须在订阅端作为有效的目标表存在。（它们既可以本身也是叶子分区，也可以进一步再分区，甚至可以是独立表。）发布还可以指定，复制变更时改用分区根表的标识和模式，而不是使用实际产生变更的各个叶子分区的标识和模式（见 CREATE PUBLICATION 的 publish_via_partition_root 参数）。

对已发布表使用 REPLICA IDENTITY FULL 时，需要注意：如果表中包含某些数据类型的属性（例如 point 或 box），而这些类型没有 B-树或 Hash 的默认操作符类，那么 UPDATE 和 DELETE 操作就无法在订阅端应用。不过，可以通过确保该表具有主键或已定义复制标识来规避这一限制。