Re: [PATCH] add concurrent_abort callback for output plugin - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [PATCH] add concurrent_abort callback for output plugin
Date
Msg-id CAA4eK1Kxe-hy5DOUziaB2JnNfGXZXvKVZYKVHoYX=_2Vky4TcQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] add concurrent_abort callback for output plugin  (Markus Wanner <markus.wanner@enterprisedb.com>)
Responses Re: [PATCH] add concurrent_abort callback for output plugin
List pgsql-hackers
On Fri, Mar 26, 2021 at 5:50 PM Markus Wanner
<markus.wanner@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.



pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: Extend more usecase for planning time partition pruning and init partition pruning.
Next
From: Noah Misch
Date:
Subject: Re: non-HOT update not looking at FSM for large tuple update