La réplication logique se comporte de la même manière pour les opérations DML dans le sens où les données seront mises à jour même si la modification a été faite en local sur la base abonnée. Si les données entrantes entrainent des violations de contrainte d'intégrité, la réplication s'arrête. Cela sera référencé comme un conflit. Lorsque l'on réplique des opérations UPDATE ou DELETE, les données manquantes ne produiront pas de conflit et des opérations de la sorte seront simplement évitées.

Les opérations de réplication logique sont réalisées avec les droits du propriétaire de la souscription. Les échecs de droit sur les tables cibles causeront des conflits de réplication, tout autant que l'activation de politiques de sécurité au niveau ligne sur des tables cibles et pour lesquels le propriétaire de la souscription est sujet des politiques de sécurité, sans chercher si une politique rejetterait habituellement les opérations INSERT, UPDATE, DELETE ou TRUNCATE en cours de réplication. Cette restriction sur les politiques de sécurité niveau ligne pourrait être supprimée dans une prochaine version de PostgreSQL.

Lorsqu'un conflit entraine une erreur, cela stoppe la réplication ; Le conflit devra être résolu manuellement par un utilisateur. Des informations détaillées concernant le conflit seront disponibles dans les journaux applicatifs de l'instance abonnée.

La résolution peut être réalisée, soit en changeant les données ou les droits sur la base abonnée pour qu'elles ne soient plus en conflit avec les données entrantes ou en évitant les transactions qui sont en conflit avec les données existantes. Quand un conflit produit une erreur, la réplication ne peut pas continuer et le processus worker de la réplication logique émet un message du type suivant dans les journaux applicatifs de l'abonné :

ERROR:  duplicate key value violates unique constraint "test_pkey"
DETAIL:  Key (c)=(1) already exists.
CONTEXT:  processing remote data for replication origin "pg_16395" during "INSERT" for replication target relation "public.test" in transaction 725 finished at 0/14C0378

Le LSN de la transaction qui contient le changement violant la contrainte et le nom d'origine de réplication peuvent être trouvés à partir du journal applicatif du serveur (LSN 0/14C0378 et origine de réplication pg_16395 dans le cas ci-dessus). La transaction qui a produit le conflit peut être ignorée en utilisant l'instruction ALTER SUBSCRIPTION ... SKIP avec le LSN final (LSN 0/14C0378). Le LSN final pourrait être un LSN sur lequel la transaction est validée ou préparée sur le publieur. La transaction peut aussi être ignorée en appelant la fonction pg_replication_origin_advance(). Avant d'utiliser cette fonction, la souscription doit être désactivée temporairement soit par ALTER SUBSCRIPTION ... DISABLE soit en utilisant l'option disable_on_error de la souscription. Ensuite, vous pouvez utiliser la fonction pg_replication_origin_advance() avec node_name (pg_16395) et le LSN suivant du LSN final (0/14C0379). La position actuelle des origines peut être trouvée dans la vue système pg_replication_origin_status. Merci de noter qu'ignorer la transaction complète inclut d'ignorer des changements qui pourraient ne pas violer des contraintes. Ceci peut rendre l'abonné incohérent très facilement.

Quand le mode streaming vaut parallel, le LSN final des transactions en échec peut ne pas être journalisé. Dans ce cas, il peut être nécessaire de changer le mode de flux (streaming) à on ou off et provoquer les même conflits encore pour que le LSN final des transactions échouées soit écrit dans le journal du serveur. Pour l'utilisation du LSN final, veuillez vous reférer à ALTER SUBSCRIPTION ... SKIP.