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

From Andres Freund
Subject Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?
Date
Msg-id 20200908191823.pmsoobzearkrmtg4@alap3.anarazel.de
Whole thread Raw
In response to Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?  (David Pirotte <dpirotte@gmail.com>)
Responses Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?  (Michael Paquier <michael@paquier.xyz>)
List 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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: INSERT ON CONFLICT and RETURNING
Next
From: Andres Freund
Date:
Subject: Re: Improving connection scalability: GetSnapshotData()