On Fri, Jul 9, 2021 at 9:02 AM Alexey Lesovsky <lesovsky@gmail.com> wrote:
>
> On Fri, Jul 9, 2021 at 5:43 AM Masahiko Sawada <sawada.mshk@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
iscleared, the error counter is required (because we don't want to lose all history of errors). If it is kept - the
flagtelling about the error is resolved is needed (or set xid to NULL). I mean when the user is watching the view, he
shouldbe 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.
