Le décodage logique correspond au processus d'extraction de tous les changements persistants sur une table d'une base de données dans un format cohérent et simple à comprendre, qui peut être interprété sans une connaissance détaillée de l'état interne de la base de données.
Dans PostgreSQL™, le décodage logique est implémenté en décodant le contenu des journaux de transaction (WAL), qui décrivent les changements au niveau stockage, dans un format spécifique tel que le flux de lignes ou des ordres SQL.
Dans le contexte de la réplication logique, un slot représent un flux de changements qui peut être rejoué par un client, dans l'ordre dans lequel ils ont été effectués sur le serveur d'origine. Chaque slot envoie dans ce flux une séquence de changements d'une unique base en envoyant chaque changement une seule et unique fois (sauf utilisation de la prévisualisation dans le flux).
![[Note]](../images/note.png)
PostgreSQL™ possède également des slots de réplication (voir Section 25.2.5, « Streaming Replication »), mais ceux-ci sont utilisés de manière un peu différente ici.
Les slots de réplication ont un identifiant qui est unique à travers toutes les bases d'une instance PostgreSQL™. Les slots persistent indépendamment de la connexion les utilisant et sont résistants à un arrêt brutal.
De nombreux slots indépendants peuvent exister pour une même base. Chaque slot possède son propre état, autorisant différents consommateurs à recevoir des changements depuis différents points dans le flux de changement de la base. Pour la plupart des utilisations, un slot séparé sera requis pour chaque consommateur.
Un slot de réplication logique ne sait rien sur l'état du ou des destinataire(s). Il est même possible d'avoir plusieurs destinataires différents utilisant un même slot à des moments différents; ils ne recevront que les changements à partir de là où le dernier destinataire a arrêté de les consommer. Un seul destinataire peut consommer les changements d'un slot à un instant donné.
Les slots de réplications persistent après un arrêt brutal et ne connaissent rien de l'état de leur(s) consommateur(s). Ils empêcheront la suppression automatique des ressources nécessaires même si aucune connexion ne les utilise. Cela consomme de l'espace car aucun des journaux de transactions et aucune des lignes des catalogues systèmes requis ne peuvent être supprimés par VACUUM tant qu'ils sont requis par un slot de réplication. Par conséquent, si un slot n'est plus nécessaire, il devrait être supprimé.
Les plugins de sortie transforment les données depuis la représentation interne dans les journaux de transactions (WAL) vers le format dont le consommateur d'un slot de réplication a besoin.
Quand un nouveau slot de réplication est créé avec l'interface de la réplication en flux, un instantané est exporté (voir Section 9.26.5, « Fonctions de synchronisation des images de base »), qui montrera exactement l'état de la base de données après lequel tous les changements seront inclus dans le flux de changement. Cela peut être utilisé pour créer un nouveau réplicat en utilisant SET TRANSACTION SNAPSHOT pour lire l'état de la base au moment où le slot a été créé. Cette transaction peut alors être utilisée pour exporter l'état de la base à ce point dans le temps, lequel peut ensuite être mis à jour en utilisant le contenu des slots sans perdre le moindre changement.
Décodage logique (Logical
Decoding)