PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 16.6 » Programmation serveur » Décodage logique (Logical Decoding) » Support de la réplication synchrone pour le décodage logique

49.8. Support de la réplication synchrone pour le décodage logique #

49.8.1. Aperçu #

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 49.3) doit être utilisée pour renvoyer par flux les données. Les clients doivent envoyer des messages Standby status update (F) (voir Section 55.4), tout comme le font les clients de réplication par flux.

Note

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.

49.8.2. Mises en garde #

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 49.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 pouvant causer des deadlocks s'appliquent non seulement aux tables du catalogue système indiquées explicitement mais aussi aux autres tables du catalogue utilisateur.