From 74da4c71d6b1fc20c546ab042135f444dd21e734 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 10 Nov 2021 13:12:58 -0500 Subject: [PATCH] Doc: improve protocol spec for logical replication Type messages. protocol.sgml documented the layout for Type messages, but completely dropped the ball otherwise, failing to explain what they are, when they are sent, or what they're good for. While at it, do a little copy-editing on the description of Relation messages. In passing, adjust the comment for apply_handle_type() to make it clearer that we choose not to do anything when receiving a Type message, not that we think it has no use whatsoever. Per question from Stefen Hillman. Discussion: https://postgr.es/m/CAPgW8pMknK5pup6=T4a_UG=Cz80Rgp=KONqJmTdHfaZb0RvnFg@mail.gmail.com --- doc/src/sgml/protocol.sgml | 26 +++++++++++++++++------- src/backend/replication/logical/worker.c | 5 ++++- 2 files changed, 23 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index 164879b42d..1f425a08de 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -2903,13 +2903,25 @@ The commands accepted in replication mode are: - Every DML message contains an arbitrary relation ID, which can be mapped to - an ID in the Relation messages. The Relation messages describe the schema of the - given relation. The Relation message is sent for a given relation either - because it is the first time we send a DML message for given relation in the - current session or because the relation definition has changed since the - last Relation message was sent for it. The protocol assumes that the client - is capable of caching the metadata for as many relations as needed. + Every DML message contains a relation OID, identifying the publisher's + relation that was acted on. Before the first DML message for a given + relation OID, a Relation message will be sent, describing the schema of + that relation. Subsequently, a new Relation message will be sent if + the relation's definition has changed since the last Relation message + was sent for it. (The protocol assumes that the client is capable of + remembering this metadata for as many relations as needed.) + + + + Relation messages identify column types by their OIDs. In the case + of a built-in type, it is assumed that the client can look up that + type OID locally, so no additional data is needed. For a non-built-in + type OID, a Type message will be sent before the Relation message, + to provide the type name associated with that OID. Thus, a client that + needs to specifically identify the types of relation columns should + cache the contents of Type messages, and first consult that cache to + see if the type OID is defined there. If not, look up the type OID + locally. diff --git a/src/backend/replication/logical/worker.c b/src/backend/replication/logical/worker.c index d7b3446e75..833b2809d0 100644 --- a/src/backend/replication/logical/worker.c +++ b/src/backend/replication/logical/worker.c @@ -1196,7 +1196,10 @@ apply_handle_relation(StringInfo s) /* * Handle TYPE message. * - * This is now vestigial; we read the info and discard it. + * This implementation pays no attention to TYPE messages; we expect the user + * to have set things up so that the incoming data is acceptable to the input + * functions for the locally subscribed tables. Hence, we just read and + * discard the message. */ static void apply_handle_type(StringInfo s)