Cette section décrit le format détaillé de chaque message de réplication logique. Ces messages sont renvoyés soit par l'interface SQL du slot de réplication soit par un walsender. Dans ce dernier cas, ils sont encapsulés à l'intérieur de messages WAL du protocole de réplication, comme décrit dans Section 55.4, et obéissent généralement au même flux de message que la réplication physique.
Identifie le message comme un message begin.
Le LSN final de la transaction.
Horodatage de la validation de la transaction. La valeur est un nombre de microsecondes depuis l'epoch PostgreSQL (1er janvier 2000).
Xid de la transaction.
Identifie the message comme un message de décodage logique.
Xid de la transaction (seulement présent pour les transactions en flux). Ce champ est disponible depuis la version 2 du protocole.
Drapeaux ; soit 0 pour aucun drapeau, ou 1 si le message de décodage logique est transactionnel.
Le LSN du message de décodage logique.
Le préfixe du message de décodage logique.
Longueur du contenu.
nLe contenu du message de décodage logique.
Identifie le message comme un message de Commit.
Drapeaux ; actuellement inutilisé.
Le LSN du commit.
Le LSN de fin de la transaction.
Horodatage de la validation de la transaction. La valeur est en nombre de microsecondes depuis l'epoch PostgreSQL (1er janvier 2000).
Identifie le message comme un message Origin.
Le LSN de la validation sur le serveur d'origine.
Nom de l'origine.
Notez qu'il peut y avoir plusieurs messages Origin dans une même transaction.
Identifie le message comme un message Relation.
XID de la transaction (seulement présent pour les transactions en flux). Ce champ est disponible à partir de la version 2 du protocole.
OID de la relation.
Schéma (chaîne vide pour pg_catalog).
Nom de la relation.
Configuration de l'identité de réplication pour la relation (identique
à relreplident dans
pg_class).
Nombre de colonnes.
Ensuite, la partie suivante du message apparaît pour chaque colonne inclus dans la publication, à l'exception des colonnes générées :
Drapeaux pour la colonne. Actuellement, peut valoir soit 0 pour aucun drapeau ou 1 pour marquer la colonne comme faisant partie de la clé.
Nom de la colonne.
OID du type de données de la colonne.
Modifieur de type de la colonne (atttypmod).
Identifie le message comme un message Type.
XID de la transaction (seulement présent pour les transactions en flux). Ce champ est disponible depuis la version 2 du protocole.
OID du type de données.
Schéma (chaîne vide pour pg_catalog).
Nom du type de données.
Identifie le message comme un message Insert.
XID de la transaction (seulement présent pour les transactions en flux). Ce champ est disponible depuis la version 2 du protocole.
OID de la relation correspondant ç l'identifiant du message Relation message.
Identifie le message TupleData suivant comme une nouvelle ligne.
Message TupleData représentant le contenu de la nouvelle ligne.
Identifie le message comme un message Update.
XID de la transaction (seulement présent pour les transactions en flux). Ce champ est disponible depuis la version 2 du protocole.
OID de la relation correspondant à l'identifiant du message Relation message.
Identifie les sous-messages TupleData suivants comme une clé. Ce champ est optionnel et est présent uniquement si la mise à jour a modifié des données dans une des colonnes qui font partie de l'index REPLICA IDENTITY.
Identifie les sous-messages TupleData suivants comme une ancienne ligne. Ce champ est optionnel et est présent uniquement si la table ciblée par la mise à jour a REPLICA IDENTITY configuré à FULL.
Message TupleData représentant le contenu de l'ancienne ligne ou la clé primaire. Seulement présent si la partie 'O' ou 'K' précédente est présente.
Identifie le message TupleData suivant comme la nouvelle ligne.
Message TupleData représentant le contenu de la nouvelle ligne.
Le message Update peut contenir soit une partie d'un message 'K' soit une partie d'un message 'O', mais jamais les deux.
Identifie the message comme un message Delete.
XID de la transaction (seulement présent pour les transactions en flux). Ce champ est disponible depuis la version 2 du protocole.
OID de la relation correspondant ç l'identifiant du message Relation message.
Identifie le sous-message TupleData suivant comme une clé. Ce champ est présent si la table ciblée par la suppression utilise un index comme REPLICA IDENTITY.
Identifie le message TupleData suivant comme une ancienne ligne. Ce champ est présent si la table ciblée par la suppression a le REPLICA IDENTITY configuré à FULL.
Message TupleData représentant le contenu de l'ancienne ligne ou clé primaire, suivant le champ précédent.
Le message Delete pourrait contenir soit une partie d'un message 'K' soit une partie d'un message 'O', mais jamais les deux.
Identifie le message comme un message Truncate.
XID de la transaction (seulement présent pour les transactions en flux). Ce champ est disponible depuis la version 2 du protocole.
Nombre de relations.
Options pour TRUNCATE :
1 pour CASCADE, 2 pour RESTART
IDENTITY
OID de la relation correspondant à l'identifiant du message Relation. Ce champ est répété pour chaque relation.
Les messages suivants (Stream Start, Stream Stop, Stream Commit et Stream Abort) sont disponibles depuis la version 2 du protocole.
Identifie le message comme un message de début de flux.
Xid de la the transaction.
Une valeur de 1 indique qu'il s'agit du premier segment pour cet XID, et une valeur de 0 pour tout autre segment de flux.
Identifie le message comme un message d'arrêt de flux.
Identifie le message comme un message de validation du flux.
XID de la transaction.
Drapeaux ; actuellement inutilisé.
Le LSN de la validation.
Le LSN final de la transaction.
Horodatage de la validation de la transaction. La valeur est un nombre de microsecondes depuis l'epoch PostgreSQL (1er janvier 2000).
Identifie le message comme un message d'annulation de flux.
XID de la transaction.
XID de la sous-transaction (identique à l'XID de la transaction pour les transactions haut niveau).
Les messages suivants (Begin Prepare, Prepare, Commit Prepared, Rollback Prepared, Stream Prepare) sont disponibles depuis la version 3 du protocole.
Identifie le message comme le début d'une transaction préparée.
Le LSN de la préparation de la transaction.
Le LSN final de la transaction préparée.
Horodatage de la phase de préparation de la transaction. La valeur est en nombre de microsecondes depuis l'epoch PostgreSQL (1er janvier 2000).
XID de la transaction.
Le GID défini par l'utilisateur pour la transaction préparée.
Identifie le message comme un message de transaction préparée.
Drapeaux ; actuellement inutilisé.
Le LSN de la préparation.
Le LSN final de la transaction préparée.
Horodatage de la phase de préparation de la transaction. La valeur est en nombre de microsecondes depuis l'epoch PostgreSQL (1er janvier 2000).
XID de la transaction.
Le GID défini par l'utilisateur pour la transaction préparée.
Identifie le message comme le message de validation d'une transaction préparée.
Drapeaux ; actuellement inutilisé.
Le LSN de la validation de la transaction préparée.
Le LSN final de la validation de la transaction préparée.
Horodatage de la validation de la transaction. La valeur est en nombre de microsecondes depuis l'epoch PostgreSQL (1er janvier 2000).
XID de la transaction.
Le GID défini par l'utilisateur pour la transaction préparée.
Identifie le message comme le message d'annulation d'une transaction préparée.
Drapeaux ; actuellement inutilisé.
Le LSN final de la transaction préparée.
Le LSN final de la transaction préparée annulée.
Horodatage de la phase de préparation de la transaction. La valeur est en nombre de microsecondes depuis l'epoch PostgreSQL (1er janvier 2000).
Horodatage de la phase d'annulation de la transaction. La valeur est en nombre de microsecondes depuis l'epoch PostgreSQL (1er janvier 2000).
XID de la transaction.
Le GID défini par l'utilisateur pour la transaction préparée.
Identifie le message comme un message de préparation en flux 2PC.
Drapeaux ; actuellement inutilisé.
Le LSN de la phase de préparation.
Le LSN final de la transaction préparée.
Horodatage de la phase de préparation de la transaction. La valeur est en nombre de microsecondes depuis l'epoch PostgreSQL (1er janvier 2000).
XID de la transaction.
Le GID défini par l'utilisateur pour la transaction préparée.
Les parties de message suivants sont partagées par les messages ci-dessus.
Nombre de colonnes.
Ensuite, un des sous-messages suivants apparaît pour chaque colonne, à l'exception des colonnes générées) :
Identifie la donnée comme une valeur NULL.
ou
Identifie la valeur TOAST non modifiée (la valeur réelle n'est pas envoyée).
ou
Identifie la donnée comme une valeur formatée en texte.
ou
Identifie la donnée comme une valeur formatée en binaire.
Longueur de la valeur de la colonne.
n
La valeur de la colonne, en format soit binaire soit texte. (Comme
spécifié dans l'octet de format précédent.)
n est la longueur ci-dessus.