This section describes the logical replication protocol, which is the message
flow started by the START_REPLICATION
SLOT slot_name
LOGICAL replication command.
The logical streaming replication protocol builds on the primitives of the physical streaming replication protocol.
The logical replication START_REPLICATION command
accepts following parameters:
Protocol version. Currently versions 1, 2,
and 3 are supported.
Version 2 is supported only for server version 14
and above, and it allows streaming of large in-progress transactions.
Version 3 is supported only for server version 15
and above, and it allows streaming of two-phase commits.
Comma separated list of publication names for which to subscribe (receive changes). The individual publication names are treated as standard objects names and can be quoted the same as needed.
Les messages individuels du protocole sont discutés dans les sous-sections suivantes. Les messages individuels sont décrits dans Section 55.9.
Tous les message haut niveau du protocole commencent avec un octet de type de message. Bien que représenté dans le code comme un caractère, c'est en fait un octet signé sans encodage associé.
Comme le protocole de réplication en flux fournit une longueur de message, il n'est pas nécessaire que les messages haut niveau du protocole embarquent une longueur dans leur en-tête.
À l'exception de la commande START_REPLICATION et des
messages de progression du rejeu, toutes les informations se déplacent
uniquement du backend vers le client.
Le protocole de réplication logique envoie les transactions individuelles l'une après l'autre. Cela signifie que tous les messages entre une paire de messages Begin et Commit appartiennent à la même transaction. De façon similaire, tous les messages entre une paire de messages Begin Prepare et Prepare appartiennent à la même transaction. Il envoie aussi les changements de grosses transactions en cours entre une paire de messages Stream Start et Stream Stop. Le dernier lot d'une telle transaction contient un message Stream Commit ou Stream Abort.
Chaque transaction envoyée contient zéro ou plusieurs messages DML (Insert, Update, Delete). Dans le cas d'une configuration en cascade, elle peut aussi contenir des messages Origin. Le message origine indique que la transaction provient d'un autre nœud de réplication. Comme un nœud de réplication peut être à peu près tout dans le cas du protocole de réplication logique, le seul identifiant est le nom de l'origine. C'est au client de gérer ceci. Le message Origin est toujours envoyé avant tout message DML dans la transaction.
Chaque message DML contient un OID de relation, identifiant la relation concernée. Avant le premier message DML pour un OID de relation donné, un message Relation sera envoyé, décrivant le schéma de cette relation. Après cela, un nouveau message Relation sera envoyé si la définition de la relation a changé depuis l'envoi du dernier message Relation. (Le protocole suppose que le client est capable de se rappeler de cette méta donnée pour toutes les relations impliquées.)
Les messages Relation identifient les types des colonnes par leur OID. Dans le cas d'un type interne, il est supposé que le client peut rechercher cet OID localement, donc aucune donnée supplémentaire n'est nécessaire. Pour les OID de type utilisateur, un message Type sera envoyé avant le message Relation pour fournir le nom du type associé à cet OID. De ce fait, un client qui a besoin d'identifier spécifiquement les types des colonnes d'une relation devrait placer en cache le contenu des messages Type, et consulter ce cache pour vérifier si l'OID du type y est défini. Dans le cas contraire, il sera possible de rechercher localement l'OID du type.
