Le décodage logique peut être utilisé pour construire des solutions de
réplication synchrone avec
la même interface utilisateur que la réplication synchrone de la réplication par flux. Pour cela,
l'interface de réplication en flux (voir Section 47.3) doit être utilisée pour renvoyer
par flux les données. Les clients doivent envoyer des messages
Standby status update (F) (voir Section 53.4), tout comme le font les clients de
réplication par flux.
Un réplica synchrone recevant des changements grâce au décodage logique
fonctionnera dans le cadre d'une seule base de données. Puisque, à
l'opposé de cela, synchronous_standby_names est
actuellement commun à toutes les instances, cela signifie que cette
technique ne marchera pas convenablement si plus d'une base de
l'instance est utilisée activement.
Dans une configuration de réplication synchrone, un verrou deadlock peut survenir si la transaction a verrouillé les tables du catalogue de façon exclusive. Voir Section 47.6.2 pour des informations sur les tables du catalogue utilisateur catalog tables. Ceci survient parce que le décodage logique des transactions peut verrouiller les tables du catalogue pour y accéder. Pour éviter ceci, les utilisateurs doivent s'empêcher de prendre un verrou exclusif sur les tables du catalogue. Ceci peut arriver dans les cas suivants :
Lancer une commande LOCK exclusive sur
pg_class dans une transaction ;
Exécuter une commande CLUSTER sur
pg_class dans une transaction ;
PREPARE TRANSACTION après une commande
LOCK sur pg_class et
autoriser le décodage logiques des transactions en deux phases ;
PREPARE TRANSACTION après une commande
CLUSTER sur pg_trigger et
autoriser le décodage logiques des transactions en deux phases. Ceci
amènera un deadlock seulement quand la table publiée a un trigger ;
Exécuter une commande TRUNCATE sur une table du
catalogue dans une transaction.
Notez que ces commandes pouvent causer des deadlocks pas seulement pour les tables du catalogue système, mais aussi pour les tables du catalogue utilisateur.
