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. However, it pretty closely replicates the transaction's state as
it was on the origin at any given point in time (by LSN).
Regards
Markus