数据库模式和 DDL 命令不会被复制。初始模式可以通过手动使用 pg_dump --schema-only 命令进行复制。后续的模式更改需要手动保持同步。（但请注意，两边的模式不必完全相同。）当现场数据库的模式发生更改时，逻辑复制是健壮的：当发布服务器上的模式发生更改，并且复制的数据开始到达订阅服务器但与表模式不匹配时，复制将出错，直到模式更新。在许多情况下，通过先在订阅服务器上应用增量模式更改，可以避免间歇性错误。

序列数据不会被复制。由序列支持的 serial 或 identity 列中的数据当然会作为表的一部分被复制，但序列本身在订阅服务器上仍将显示起始值。如果订阅服务器用作只读数据库，那么这通常不成问题。但是，如果打算进行某种切换或故障转移到订阅服务器数据库，那么需要通过从发布服务器复制当前数据（可能使用 pg_dump）或从表本身确定一个足够大的值来更新序列到最新值。

支持复制 TRUNCATE 命令，但截断由外键连接的表组时需要格外小心。复制截断操作时，订阅服务器将截断在发布服务器上被截断的同一组表，这些表要么是显式指定的，要么是通过 CASCADE 隐式收集的，但不包括不属于订阅的表。如果所有受影响的表都属于同一个订阅，这将正常工作。但是，如果订阅服务器上要截断的某些表与不属于同一订阅（或任何订阅）的表存在外键链接，那么在订阅服务器上应用截断操作将失败。

大型对象（请参阅 第 33 章）不会被复制。除了将数据存储在普通表中，没有其他解决方法。

复制仅支持表，包括分区表。尝试复制其他类型的关系，如视图、物化视图或外部表，将导致错误。

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

在使用发布表上的 REPLICA IDENTITY FULL 时，重要的是要注意，如果表包含数据类型（如 point 或 box）没有 B-tree 或 Hash 默认运算符类的属性，那么 UPDATE 和 DELETE 操作将无法应用于订阅服务器。但是，通过确保表具有主键或副本标识为其定义，可以克服此限制。