On Wed, Feb 10, 2021 at 11:45 AM Ajin Cherian <itsa...@gmail.com> wrote: > > On Wed, Feb 10, 2021 at 3:43 PM Ashutosh Bapat > <ashutosh.ba...@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 have been aborted and hence lost by the downstream and thus it needs > > to get all of those again. But when a downstream prepares a transaction, > > even if it's not committed, those changes are not lost even after restart > > of a walsender. If the downstream confirms 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.
