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
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 |