On Tue, Dec 14, 2021 at 8:20 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Dec 13, 2021 at 6:55 PM Masahiko Sawada <sawada.m...@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