Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

From: David Pirotte <dpirotte(at)gmail(dot)com>
To: Dave Cramer <davecramer(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?
Date: 2020-07-30 03:26:04
Message-ID: CAOXUAcKDddXVVMqW+fQUCYoskS_LX14fdf7RvySw3f7bTTV6NQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 29, 2020 at 9:41 PM Dave Cramer <davecramer(at)gmail(dot)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 Content-Type Size
0001-Add-logical-decoding-messages-to-pgoutput.patch.gz application/gzip 3.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-07-30 03:35:08 Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Previous Message Fujii Masao 2020-07-30 03:24:33 Re: [PATCH] Tab completion for VACUUM of partitioned tables