Re: repeated decoding of prepared transactions

Hi,

On Fri, Feb 19, 2021, at 19:38, Amit Kapila wrote:
> On Fri, Feb 19, 2021 at 8:23 PM Markus Wanner
> <markus.wanner@enterprisedb.com> wrote:
> >
> > With that line of thinking, the point in time (or in WAL) of the COMMIT
> > PREPARED does not matter at all to reason about the decoding of the
> > PREPARE operation.  Instead, there are only exactly two cases to consider:
> >
> > a) the PREPARE happened before the start_decoding_at LSN and must not be
> > decoded. (But the effects of the PREPARE must then be included in the
> > initial synchronization. If that's not supported, the output plugin
> > should not enable two-phase commit.)
> >
> 
> I see a problem with this assumption. During the initial
> synchronization, this transaction won't be visible to snapshot and we
> won't copy it. Then later if we won't decode and send it then the
> replica will be out of sync. Such a problem won't happen with Ajin's
> patch.

Why isn't the more obvious answer to this to not allow/disable 2pc decoding during the initial sync? You can't really make sense of it before you're synced anyway... 

Regards,

Andres