La réplication logique souffre actuellement des restrictions ou des fonctionnalités manquantes suivantes. Elles pourraient être adressées dans les prochaines versions.
La structure de la base de données et les commandes DDL ne sont pas
répliquées. Le schéma initial peut être copié à la main en utilisant la
commande pg_dump --schema-only
. Les modifications de
schéma suivantes auront besoin d'être synchronisées manuellement. (Notez,
néanmoins, qu'il n'est pas nécessaire que les schémas soient strictement
identiques des deux côtés.) La réplication logique est robuste quand il y a
des modifications de schéma dans une base de données. Quand le schéma est
changé sur le publieur et les données répliquées commencent à arriver sur
l'abonné mais ne correspondent pas à la structure de la table, la
réplication renverra une erreur jusqu'à ce que le schéma soit mis à jour.
Dans de nombreux cas, les erreurs intermittentes peuvent être évitées en
appliquant des modifications de schéma à l'abonné en premier ;
Les données des séquences ne sont pas répliquées. Les données des colonnes
de type serial et des colonnes identité, gérées par des séquences, seront
bien sûr répliquées comme faisant partie de la table, mais la séquence
elle-même affichera toujours la valeur de démarrage sur l'abonné. Si
l'abonné est utilisé comme une base de données en lecture seule, alors cela
ne devrait pas être un problème. Néanmoins, s'il est nécessaire de faire un
bascule (switchover ou
failover sur la base de données abonnée,
alors les séquences auront besoin d'être mises à jour à leur dernières
valeurs, soit en copiant les données courantes du publieur (peut-être en
utilisant pg_dump
), soit en déterminant une valeur
suffisamment haute à partir des données de la table ;
La réplication des commandes TRUNCATE
est supportée mais
il est nécessaire de prêter attention lors de l'utilisation de cette
commande sur des groupes de tables connectés par des clés étrangères. Lors
de la réplication d'une action truncate, l'abonné tronquera le même groupe
de tables tronquées sur le publieur, qu'elles soient spécifiées
explicitement ou implicitement (grâce à la clause
CASCADE
), moins les tables qui ne font pas partie de la
souscription. Ceci fonctionnera correctement si toutes les tables affectées
font partie de la même souscription. Cependant, si certaines tables à
tronquer ont des clés étrangères vers des tables qui ne font pas partie de
la même souscription, alors l'application de l'action truncate échouera sur
le serveur abonné ;
Les Large Objects (voir Chapitre 35) ne sont pas répliqués. Il n'y a pas de contournement pour ça, en dehors d'enregistrer les données dans des tables normales ;
La réplication est seulement supportée par les tables, y compris les tables partitionnées. Toute tentative de répliquer d'autres types de relation, comme les vues, les vues matérialisées ou les tables externes, résultera en une erreur ;
Lors de la réplication entre tables partitionnées, la réplication actuelle
a pour origine, par défaut, les partitions filles sur le publieur, donc les
partitions sur le publieur doivent exister aussi sur l'abonné en tant que
tables cibles valides. Elles peuvent être soit des partitions filles
elles-mêmes, soit de nouveau sous-partitionnées, soit des tables
indépendantes. Les publications peuvent aussi spécifier les changements à
répliquer en utilisant l'identité et le schéma de la table racine
partitionnée au lieu de chaque partition individuelle à l'origine des
changements (voir le paramètre
publish_via_partition_root
de CREATE PUBLICATION
).