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

On Tue, Jun 23, 2026 at 1:52 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, Jun 23, 2026 at 4:09 AM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> >
> > 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.
> >
>
> I think it is important to have some example extension implementation
> to see how the hook could be utilized. One more use of such a hook
> could be to use for audit of DDLs replayed on subscribers.

Right. I'm implementing a basic DDL replication solution using this
hook as a sample implementation. Other than that, this feature can be
used to add additional information for the replicated transaction that
is not replicated via logical replication protocol, such as the
executed user or context-specific information, which can then be
dispatched to a CDC system connected to the subscriber.

> BTW, can we
> also consider it as a solution implementing basic DDL replication for
> tables? The key question is what if someday we have in-core DDL
> replication. I think extensions can still be used to implement
> filtering or transformation of DDL. We can implement capture of DDL
> using JSON format [1] so that it is forward compatible with in-core
> DDL replication. So considering that, the extension handlers will look
> like:

While a common JSON format might be helpful for forward compatibility
with in-core DDL replication, I think that we need to keep the generic
logical decoding messages used by this feature distinct from the
messages that would be used for DDL replication. A generic logical
decoding message can be written via pg_logical_emit_message() SQL
function, which is granted to PUBLIC, so any user could directly emit
a DDL command in the JSON format with the 'pg_ddl' prefix and create
arbitrary tables on the subscriber, which could cause a privilege
escalation problem. I don't think we should build something as
powerful as DDL execution on top of a message channel that any user
can write to.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com