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

From David Pirotte
Subject Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?
Date
Msg-id CAOXUAc+hKMms7cHdfhb4UcZGb3aVSe+Bephwue0Or7zhnOoM7A@mail.gmail.com
Whole thread Raw
In response to Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?  (Dave Cramer <davecramer@gmail.com>)
Responses Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
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 
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Move OpenSSL random under USE_OPENSSL_RANDOM
Next
From: Masahiko Sawada
Date:
Subject: Re: Some doubious code in pgstat.c