On Tue, Jun 23, 2026 at 1:52 AM Amit Kapila <[email protected]> wrote: > > On Tue, Jun 23, 2026 at 4:09 AM Bharath Rupireddy > <[email protected]> wrote: > > > > On Fri, Jun 19, 2026 at 3:34 PM Masahiko Sawada <[email protected]> > > 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
