数据库模式和 DDL 命令不会被复制。初始模式可以手工使用 pg_dump --schema-only 进行拷贝。后续的模式改变需要手工保持同步（不过值得注意的是，模式 其实不需要在两端保持绝对相同）。当一个活跃的数据库中模式定义改变时，逻辑复制是鲁棒的： 当模式在发布者上发生改变并且被复制的数据开始到达订阅者但却不适合表模式时，复制将报错， 直至模式被更新。在很多情况下，可以通过先对订阅者应用额外的模式更改来避免间歇性的错误。

序列数据不被复制。后台由序列支撑的 serial 或者标识列中的数据当然将被作为表的一部分复制， 但是序列本身在订阅者上仍将显示开始值。如果订阅者被用作一个只读数据库，那么这通常不会是什么问题。 不过，如果订阅者数据库预期有某种转换或者容错，那么序列需要被更新到最新的值，要么通过从发布者拷贝 当前数据（也许使用 pg_dump），要么从表本身决定一个足够高的值。

支持 TRUNCATE 命令的复制，但是在截断由外键连接在一起的表群体时必须要小心。 在复制截断动作时，订阅者将截断与发布者上被截断的相同的表群体，这些表或者被明确指定或者通过 CASCADE 隐含地收集而来，然后还要减去不属于该订阅的表。如果所有受影响的表都属于 同一个订阅，这会正确地工作。但是如果订阅者上要被截断的某些表有外键链接到不属于同一订阅的表， 那么在订阅者上该截断动作的应用将会失败。

大对象（见 第 33 章）不会被复制。没有办法可以解决这个问题，除非把数据存储在普通表中。

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

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

使用 REPLICA IDENTITY FULL 在发布的表上时，重要的是要注意，如果表中包含没有默认 B-tree 或 Hash 操作符类的数据类型（例如 point 或 box）的属性， 则 UPDATE 和 DELETE 操作不能应用于订阅者。 但是，可以通过确保表定义了主键或副本标识来克服此限制。