31.7. Security
A user able to modify the schema of subscriber-side tables can execute arbitrary code as a superuser. Limit ownership andTRIGGER 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 subscriptionFOR ALL TABLES only when superusers trust every user permitted to create a non-temp table on the publisher or the subscriber.
The role used for the replication connection must have theREPLICATION attribute (or be a superuser). If the role lacksSUPERUSER andBYPASSRLS, publisher row security policies can execute. If the role does not trust all table owners, includeoptions=-crow_security=off in 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 inpg_hba.conf and it must have theLOGIN attribute.
In order to be able to copy the initial table data, the role used for the replication connection must have theSELECT privilege on a published table (or be a superuser).
To create a publication, the user must have theCREATE 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.