On Fri, Jul 9, 2021 at 9:02 AM Alexey Lesovsky <lesov...@gmail.com> wrote: > > On Fri, Jul 9, 2021 at 5:43 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: >> >> > I also would like to clarify, when conflict is resolved - the error record >> > is cleared or kept in the view? If it is cleared, the error counter is >> > required (because we don't want to lose all history of errors). If it is >> > kept - the flag telling about the error is resolved is needed (or set xid >> > to NULL). I mean when the user is watching the view, he should be able to >> > identify if the error has already been resolved or not. >> >> With the current patch, once the conflict is resolved by skipping the >> transaction in question, its entry on the stats view is cleared. As >> you suggested, if we have the total error counts in that view, it >> would be good to keep the count and clear other fields such as xid, >> last_failure, and command etc. > > > Ok, looks nice. But I am curious how this will work in the case when there > are two (or more) errors in the same subscription, but different relations? >
We can't proceed unless the first error is resolved, so there shouldn't be multiple unresolved errors. However, there is an exception to it which is during initial table sync and I think the view should have separate rows for each table sync. -- With Regards, Amit Kapila.
