Re: [PATCH] add concurrent_abort callback for output plugin

Markus Wanner <markus.wanner@enterprisedb.com>

From: Markus Wanner <markus.wanner@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Ajin Cherian <itsajin@gmail.com>
Date: 2021-03-29T07:06:50Z
Lists: pgsql-hackers
On 27.03.21 07:37, Amit Kapila wrote:
> Isn't it better to send prepare from the publisher in such a case so
> that subscribers can know about it when rollback prepared arrives?

That's exactly what this callback allows (among other options).  It 
provides a way for the output plugin to react to a transaction aborting 
while it is being decoded.  This would not be possible without this 
additional callback.

Also note that I would like to retain the option to do some basic 
protocol validity checks.  Certain messages only make sense within a 
transaction ('U'pdate, 'C'ommit).  Others are only valid outside of a 
transaction ('B'egin, begin_prepare_cb).  This is only possible if the 
output plugin has a callback for every entry into and exit out of a 
transaction (being decoded).  This used to be the case prior to 2PC 
decoding and this patch re-establishes that.

> I think we have already done the same (sent prepare, exactly to handle
> the case you have described above) for *streamed* transactions.

Where can I find that?  ISTM streaming transactions have the same issue: 
the output plugin does not (or only implicitly) learn about a concurrent 
abort of the transaction.

Regards

Markus



Commits

  1. Avoid sending prepare multiple times while decoding.

  2. Ensure to send a prepare after we detect concurrent abort during decoding.