On Tue, Dec 14, 2021 at 8:20 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Dec 13, 2021 at 6:55 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > In streaming cases, we don’t know when stream-commit or stream-abort
> > comes and another conflict could occur on the subscription in the
> > meanwhile. But given that (we expect) this feature is used after the
> > apply worker enters into an error loop, this is unlikely to happen in
> > practice unless the user sets the wrong XID. Similarly, in 2PC cases,
> > we don’t know when commit-prepared or rollback-prepared comes and
> > another conflict could occur in the meanwhile. But this could occur in
> > practice even if the user specified the correct XID. Therefore, if we
> > disallow to change skip_xid until the subscriber receives
> > commit-prepared or rollback-prepared, we cannot skip the second
> > transaction that conflicts with data on the subscriber.
> >
>
> I agree with this theory. Can we reflect this in comments so that in
> the future we know why we didn't pursue this direction?
I might be missing something here, but for streaming, transaction
users can decide whether they wants to skip or not only once we start
applying no? I mean only once we start applying the changes we can
get some errors and by that time we must be having all the changes for
the transaction. So I do not understand the point we are trying to
discuss here?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com