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

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

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

要向发布添加表，用户必须拥有该表的所有权。要将模式中的所有表添加到发布，用户必须是超级用户。要创建自动发布所有表或模式中所有表的发布，用户必须是超级用户。

目前对发布没有权限控制。任何（能够连接的）订阅都可以访问任何发布。因此，如果您打算通过行过滤器或列列表隐藏某些信息（例如），或者不将整个表添加到发布中，请注意，同一数据库中的其他发布也可能暴露相同的信息。将来可能会在 PostgreSQL 中添加发布权限，以实现更细粒度的访问控制。

要创建订阅，用户必须具有 pg_create_subscription 角色的权限，以及数据库的 CREATE 权限。

订阅应用进程将在会话级别以订阅所有者的权限运行。但是，当对特定表执行插入、更新、删除或截断操作时，它将切换角色到表所有者，并以表所有者的权限执行操作。这意味着订阅所有者需要能够 SET ROLE 到拥有已复制表的每个角色。

如果订阅已配置为 run_as_owner = true，则不会发生用户切换。相反，所有操作都将以订阅所有者的权限执行。在这种情况下，订阅所有者只需要 SELECT、INSERT、UPDATE 和 DELETE 目标表的权限，而无需 SET ROLE 到表所有者的权限。但是，这也意味着任何拥有正在被复制的表的用户都可以以订阅所有者的权限执行任意代码。例如，他们可以通过简单地向他们拥有的表之一附加触发器来做到这一点。由于通常不希望允许一个角色随意假定另一个角色的权限，因此应避免使用此选项，除非数据库中的用户安全性无关紧要。

在发布者上，权限仅在复制连接开始时检查一次，并且在读取每个更改记录时不会重新检查。

在订阅者上，订阅所有者的权限在应用每个事务时都会重新检查。如果一个工作进程在当前事务的应用过程中，由于并发事务导致订阅的所有权发生更改，则当前事务的应用将继续以旧所有者的权限进行。