On Wed, Feb 10, 2021 at 11:45 AM Ajin Cherian <itsajin@gmail.com> wrote:
>
> On Wed, Feb 10, 2021 at 3:43 PM Ashutosh Bapat
> <ashutosh.bapat@enterprisedb.com> wrote:
>
>
> > I think we need to treat a prepared transaction slightly different from an uncommitted transaction when sending
downstream.We need to send a whole uncommitted transaction downstream again because previously applied changes must
havebeen aborted and hence lost by the downstream and thus it needs to get all of those again. But when a downstream
preparesa transaction, even if it's not committed, those changes are not lost even after restart of a walsender. If the
downstreamconfirms that it has "flushed" PREPARE, there is no need to send all the changes again.
>
> 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.
--
With Regards,
Amit Kapila.
