On Fri, Mar 26, 2021 at 5:50 PM Markus Wanner <markus.wan...@enterprisedb.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.