On 10.02.21 07:32, Amit Kapila wrote:
> On Wed, Feb 10, 2021 at 11:45 AM Ajin Cherian <itsajin@gmail.com> wrote:
>> But the other side of the problem is that ,without this, if the
>> prepared transaction is prior to a consistent snapshot when decoding
>> starts/restarts, then only the "commit prepared" is sent to downstream
>> (as seen in the test scenario I shared above), and downstream has to
>> error away the commit prepared because it does not have the
>> corresponding prepared transaction.
>
> I think it is not only simple error handling, it is required for
> data-consistency. We need to send the transactions whose commits are
> encountered after a consistent snapshot is reached.
I'm with Ashutosh here. If a replica is properly in sync, it knows
about prepared transactions and all the gids of those. Sending the
transactional changes and the prepare again is inconsistent.
The point of a two-phase transaction is to have two phases. An output
plugin must have the chance of treating them as independent events.
Once a PREPARE is confirmed, it must not be sent again. Even if the
transaction is still in-progress and its changes are not yet visible on
the origin node.
Regards
Markus
