Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

David Pirotte <dpirotte@gmail.com>

From: David Pirotte <dpirotte@gmail.com>
To: Dave Cramer <davecramer@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-11-05T03:46:13Z
Lists: pgsql-hackers

Attachments

On Tue, Nov 3, 2020 at 7:19 AM Dave Cramer <davecramer@gmail.com> wrote:

> David,
>
> On Thu, 24 Sep 2020 at 00:22, Michael Paquier <michael@paquier.xyz> wrote:
>
>> On Tue, Sep 08, 2020 at 12:18:23PM -0700, Andres Freund wrote:
>> > A test verifying that a non-transactional message in later aborted
>> > transaction is handled correctly would be good.
>>
>> On top of that, the patch needs a rebase as it visibly fails to apply,
>> per the CF bot.
>> --
>> Michael
>>
>
> Where are you with this? Are you able to work on it ?
> Dave Cramer
>

Apologies for the delay, here.

I've attached v2 of this patch which applies cleanly to master. The patch
also now includes a test demonstrating that pg_logical_emit_message
correctly sends non-transactional messages when called inside a transaction
that is rolled back. (Thank you, Andres, for this suggestion.) The only
other change is that I added this new message type into the
LogicalRepMsgType enum added earlier this week.

Let me know what you think.

Cheers,
Dave

Commits

  1. Allow pgoutput to send logical decoding messages.

  2. Refactor function parse_output_parameters.