Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

From: Andres Freund <andres(at)anarazel(dot)de>
To: David Pirotte <dpirotte(at)gmail(dot)com>
Cc: Dave Cramer <davecramer(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?
Date: 2020-09-08 19:18:23
Message-ID: 20200908191823.pmsoobzearkrmtg4@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-07-29 22:26:04 -0500, David Pirotte wrote:
> 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.

Yea, it's really useful for this kind of thing.

> @@ -119,14 +124,16 @@ _PG_output_plugin_init(OutputPluginCallbacks *cb)
>
> static void
> parse_output_parameters(List *options, uint32 *protocol_version,
> - List **publication_names, bool *binary)
> + List **publication_names, bool *binary, bool *messages)

I think it might be time to add a PgOutputParameters struct, instead of
adding more and more output parameters to
parse_output_parameters. Alternatively just passing PGOutputData owuld
make sense.

> diff --git a/src/test/subscription/t/015_messages.pl b/src/test/subscription/t/015_messages.pl
> new file mode 100644
> index 0000000000..4709e69f4e
> --- /dev/null
> +++ b/src/test/subscription/t/015_messages.pl

A test verifying that a non-transactional message in later aborted
transaction is handled correctly would be good.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-09-08 19:19:01 Re: Improving connection scalability: GetSnapshotData()
Previous Message Pavel Stehule 2020-09-08 19:15:02 Re: INSERT ON CONFLICT and RETURNING