On Mon, Mar 29, 2021 at 12:36 PM Markus Wanner
<markus.wanner@enterprisedb.com> wrote:
>
> 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.
>
You don't need an additional callback for that if we do what I am
suggesting above.
> 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.
>
One is you can try to test it, otherwise, there are comments atop
DecodePrepare() ("Note that we don't skip prepare even if have
detected concurrent abort because it is quite possible that ....")
which explains this.
--
With Regards,
Amit Kapila.
