Documentation PostgreSQL 15.15 » Programmation serveur » Décodage logique (Logical Decoding) » Support de la réplication synchrone pour le décodage logique

Précédent | Niveau supérieur | Suivant
49.7. Écrivains de sortie de décodage logique | Sommaire | 49.9. Envoi en flux de grosses transactions pour le décodage logique

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

### 49.8.1. Overview

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 logique des transactions en deux phases ;

- `PREPARE TRANSACTION` après une commande `CLUSTER` sur `pg_trigger` et autoriser le décodage logique 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.