用于复制连接的角色必须具有 REPLICATION 属性 （或为超级用户）。如果该角色既没有 SUPERUSER，也没有 BYPASSRLS，则发布端的行安全性策略可能会生效。如果该角色 不信任所有表所有者，请在连接字符串中包含 options=-crow_security=off；这样一来，如果某个表所有者随后 添加了行安全性策略，复制将停止，而不是执行该策略。该角色的访问权限必须在 pg_hba.conf 中配置，并且它还必须具有 LOGIN 属性。

为了能够复制初始表数据，用于复制连接的角色必须对已发布的表具有 SELECT 权限（或者是超级用户）。

要创建发布，用户必须在数据库中具有 CREATE 权限。

要向发布中添加表，用户必须拥有该表。要向发布中添加某个模式中的全部表，用户 必须是超级用户。要创建一个会自动发布所有表，或自动发布某个模式中全部表的发布， 用户也必须是超级用户。

目前发布没有权限控制。任何订阅（只要能够连接）都可以访问任何发布。因此， 如果你打算向某些订阅者隐藏部分信息，例如通过行过滤器、列列表，或者通过不把整张表 加入发布来实现，需要注意：同一数据库中的其他发布仍可能暴露这些信息。未来版本的 PostgreSQL 可能会增加发布权限，以支持更细粒度的 访问控制。

要创建订阅，用户必须具有 pg_create_subscription 角色的权限， 并且对该数据库具有 CREATE 权限。

订阅应用进程在会话级别会以订阅所有者的权限运行。不过，在对某个具体表执行 insert、update、delete 或 truncate 操作时，它会切换角色到该表所有者，并以 表所有者的权限执行该操作。这意味着，订阅所有者必须能够对每个复制表的所有者执行 SET ROLE。

如果订阅配置了 run_as_owner = true，则不会发生用户切换。 取而代之的是，所有操作都将以订阅所有者的权限执行。在这种情况下，订阅所有者只需 具备对目标表执行 SELECT、INSERT、 UPDATE 和 DELETE 的权限，而不需要 具备对表所有者执行 SET ROLE 的权限。不过，这也意味着， 任何拥有正在接收复制数据的表的用户，都可以以订阅所有者的权限执行任意代码。 例如，他们只需在自己拥有的某张表上附加一个触发器即可。由于通常并不希望允许一个 角色自由取得另一个角色的权限，因此除非数据库内部的用户安全完全不重要，否则应避免 使用该选项。

在发布端，权限只在复制连接开始时检查一次，在读取每条变更记录时不会重新检查。

在订阅端，订阅所有者的权限会在每个事务应用时重新检查。如果某个工作者正在应用 事务时，订阅的所有权被并发事务更改，那么当前事务的应用仍会继续使用旧所有者的 权限。