Un utilisateur capable de modifier le schéma des tables côté souscription peut exécuter un code arbitraire en tant que le rôle propriétaire de la souscription qui modifie ces tables. Limitez le propriétaire et le droit TRIGGER sur ces tables aux rôles de confiance. Néanmoins, si des utilisateurs sans confiance peuvent créer des tables, utilisez seulement des publications qui listent explicitement les tables. Autrement dit, créez une souscription FOR ALL TABLES ou FOR TABLES IN SCHEMA uniquement quand les superutilisateurs ont confiance en tous les utilisateurs autorisés à créer une table non temporaire sur le publieur ou sur l'abonné.

Le rôle utilisée pour la réplication doit avoir l'attribut REPLICATION (ou être un superutilisateur). Si le rôle ne dispose pas des attributs SUPERUSER et BYPASSRLS, les politiques de sécurité niveau ligne du publieur peuvent s'exécuter. Si le rôle n'a pas confiance en tous les propriétaires de tables, incluez options=-crow_security=off dans la chaîne de connexion ;: si un propriétaire de table ajoute ensuite une politique de sécurité de ligne, cette configuration imposera un arrêt de la réplication plutôt qu'une exécution de la politique. L'accès de ce rôle à l'instance doit avoir été déclaré dans pg_hba.conf et ce rôle doit avoir l'attribut LOGIN.

Pour être capable de copier les données originales de la table, le rôle utilisé pour la connexion de réplication doit avoir le droit SELECT sur une table publiée (ou être un superutilisateur).

Pour créer une publication, l'utilisateur doit avoir le droit CREATE pour la base de données.

Pour ajouter des tables à une publication, l'utilisateur doit être propriétaire de ces tables. Pour ajouter toutes les tables d'un schéma dans une publication, l'utilisateur doit avoir l'attribut SUPERUSER. Pour créer une publication qui publie toutes les tables ou toutes les tables d'un schéma automatiquement, l'utilisateur doit avoir l'attribut SUPERUSER.

Pour créer un abonnement, l'utilisateur doit avoir les droits de superutilisateur.

Le processus apply lié à un abonnement tournera sur la base de données locale avec les droits d'un propriétaire de l'abonnement.

Sur le publieur, les droits sont vérifiés uniquement au démarrage de la connexion de réplication et ne sont pas vérifiés de nouveau à chaque fois qu'un enregistrement de changement est lu.

Sur l'abonné, les droits du propriétaire de la souscription sont vérifiés à chaque application d'une transaction. Si un processus worker est en cours de traitement pour appliquer une transaction au moment où le propriétaire de la souscription est changé dans une transaction concurrente, l'application de la transaction en cours continuera sous les droits de l'ancien propriétaire.