Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput? - Mailing list pgsql-hackers

From David Pirotte
Subject Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?
Date
Msg-id CAOXUAcKDddXVVMqW+fQUCYoskS_LX14fdf7RvySw3f7bTTV6NQ@mail.gmail.com
Whole thread Raw
In response to Any objections to implementing LogicalDecodeMessageCB for pgoutput?  (Dave Cramer <davecramer@gmail.com>)
Responses Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?  (Cary Huang <cary.huang@highgo.ca>)
Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Jul 29, 2020 at 9:41 PM Dave Cramer <davecramer@gmail.com> wrote:
For logical replication there is no need to implement this, but others are using the pgoutput plugin for Change Data Capture. The reason they are using pgoutput is because it is guaranteed to be available as it is in core postgres. 

Implementing LogicalDecodeMessageCB provides some synchronization facility that is not easily replicated.

Thoughts ?

Attached is a draft patch that adds this functionality into the pgoutput plugin. A slot consumer can pass 'messages' as an option to include logical messages from pg_logical_emit_message in the replication flow.

FWIW, we have been using pg_logical_emit_message to send application-level events alongside our change-data-capture for about two years, and we would move this part of our stack to pgoutput if message support was available. 

Looking forward to discussion and feedback.

Cheers,
Dave
Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [PATCH] Tab completion for VACUUM of partitioned tables
Next
From: Peter Geoghegan
Date:
Subject: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.