Horton

Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

David Pirotte <dpirotte@gmail.com>

View thread View on postgr.es
From: David Pirotte <dpirotte@gmail.com>
To: Dave Cramer <davecramer@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-07-30T03:26:04Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Allow pgoutput to send logical decoding messages.

  2. Refactor function parse_output_parameters.