Re: Add a hook for handling logical decoding messages on subscribers.

Hi,

On Fri, Jun 19, 2026 at 3:34 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> Hi all,
>
> Commit ac4645c015 allows pgoutput to send logical decoding messages,
> but it's limited to applications that use the pgoutput plugin -- the
> built-in logical replication doesn't use it. I'd like to propose
> introducing a hook to the logical replication message handling so that
> extensions can plug in their own handling routine. This feature can be
> used for extensions to implement DDL replication, function
> replication, or trigger user-specific routines on the subscriber side.

Thanks for working on this!

> I've attached the PoC patch; it adds a hook function, and adds a new
> 'message' subscription option that allows the user to request the
> publisher to send logical decoding messages. Therefore, users need to
> enable the 'message' option and set up the hook function at server
> startup in order to receive the messages and trigger the hook
> function.

I understand the intent of the proposal, but I'd like to get the
bigger picture first.

Do we have any external modules that actually implement DDL
replication (or any of the listed use-cases) with a similar hook? Or
any existing discussion? I could be missing something because I
haven't looked at all the DDL replication related threads.

Another thing I'm curious about - why a hook? Is the plan to implement
DDL replication as an external module rather than in core? If DDL
replication eventually gets into core, I'd expect it to be apply-side
logic executing the decoded DDL messages directly, not something going
through a hook.

Why not a hook at apply_dispatch to give external modules more freedom
with the pgoutput plugin?

> I I went with a hook function in the patch. While it lets you chain
> the multiple hook functions, providing the registration API might be
> better, or other types of registry can also be considered.

It's hard to tell how many external modules would make use of this
hook (rather, how many external modules implementing this hook one
would allow to be installed in a production database requiring
chaining), but my first thought is that a registration-based API along
the lines of RegisterXactCallback would be cleaner and work better.

> Feedback is very welcome.

A few comments on the patch:

1/
+ bool message; /* True if the subscription wants to receive
+ * logical messages */
} Subscription;

Nit: I'd call these logical decoding messages or generic logical
messages - something to match the docs and pg_logical_emit_message.

2/
+void
+test_logical_message_handler(LogicalRepMessageData *msg)
+{
+ ereport(LOG,
+ (errmsg("received message: LSN %X/%08X, prefix: %s, message: %s",
+ LSN_FORMAT_ARGS(msg->lsn),
+ msg->prefix,
+ msg->message)));
+}

Why not have the test extension do a simple DDL/function/event-trigger
based replication? It doesn't need to be a full-blown implementation,
but to show the usefulness of this hook, it's better to have one
demonstrating the listed use-cases.

3/
+ if (subinfo->submessage)
+ appendPQExpBufferStr(query, ", message = true");

Why a subscription-level option? Why not leave the decision of whether
or not to act on the message to the external module implementers?

4/
+ /*
+ * Logical messages are handled only the (parallel) apply workers
+ */
+ if (am_tablesync_worker() || am_sequencesync_worker())
+ return;

Why these restrictions? Why not leave the decision to external module
implementers? Isn't this limiting - what if someone wants to use this
hook for the schema sync during the initial table sync phase?

5/ With this change, pg_logical_emit_message does affect the logical
replication apply if the subscriber has defined this hook. I think
it's worth mentioning in the docs for pg_logical_emit_message.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com