A user able to modify the schema of subscriber-side tables can execute
arbitrary code as a superuser. Limit ownership
TRIGGER privilege on such tables to roles that
superusers trust. Moreover, if untrusted users can create tables, use only
publications that list tables explicitly. That is to say, create a
FOR ALL TABLES only when superusers trust
every user permitted to create a non-temp table on the publisher or the
The role used for the replication connection must have
REPLICATION attribute (or be a superuser). If the
publisher row security policies can execute. If the role does not trust
all table owners, include
the connection string; if a table owner then adds a row security policy,
that setting will cause replication to halt rather than execute the policy.
Access for the role must be configured in
and it must have the
In order to be able to copy the initial table data, the role used for the
replication connection must have the
SELECT privilege on
a published table (or be a superuser).
To create a publication, the user must have the
privilege in the database.
To add tables to a publication, the user must have ownership rights on the table. To create a publication that publishes all tables automatically, the user must be a superuser.
To create a subscription, the user must be a superuser.
The subscription apply process will run in the local database with the privileges of a superuser.
Privileges are only checked once at the start of a replication connection. They are not re-checked as each change record is read from the publisher, nor are they re-checked for each change when applied.