Re: [PATCH] add concurrent_abort callback for output plugin

On Fri, Mar 26, 2021 at 5:50 PM Markus Wanner
<markus(dot)wanner(at)enterprisedb(dot)com> wrote:
>
> On 26.03.21 11:19, Amit Kapila wrote:
> > No, I am not assuming that. I am just trying to describe you that it
> > is not necessary that we will be able to detect concurrent abort in
> > each and every case.
>
> Sure. Nor am I claiming that would be necessary or that the patch
> changed anything about it.
>
> As it stands, assuming the the output plugin basically just forwards the
> events and the subscriber tries to replicate them as is, the following
> would happen on the subscriber for a concurrently aborted two-phase
> transaction:
>
> * start a transaction (begin_prepare_cb)
> * apply changes for it (change_cb)
> * digress to other, unrelated transactions (leaving unspecified what
> exactly happens to the opened transaction)
> * attempt to rollback a transaction that has not ever been prepared
> (rollback_prepared_cb)
>
> The point of the patch is for the output plugin to get proper
> transaction entry and exit callbacks. Even in the unfortunate case of a
> concurrent abort. It offers the output plugin a clean way to learn that
> the decoder stopped decoding for the current transaction and it won't
> possibly see a prepare_cb for it (despite the decoder having passed the
> PREPARE record in WAL).
>
> > The other related thing is it may not be a good idea to finish the
> > transaction
>
> You're speaking subscriber side here. And yes, I agree, the subscriber
> should not abort the transaction at a concurrent_abort. I never claimed
> it should.
>
> If you are curious, in our case I made the subscriber PREPARE the
> transaction at its end when receiving a concurrent_abort notification,
> so that the subscriber:
>
> * can hop out of that started transaction and safely proceed
> to process events for other transactions, and
> * has the transaction in the appropriate state for processing the
> subsequent rollback_prepared_cb, once that gets through
>
> That's probably not ideal in the sense that subscribers do unnecessary
> work.
>

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? I
think we have already done the same (sent prepare, exactly to handle
the case you have described above) for *streamed* transactions.

--
With Regards,
Amit Kapila.