On Mon, Jul 12, 2021 at 1:15 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Jul 12, 2021 at 9:37 AM Alexey Lesovsky <lesovsky@gmail.com> wrote:
> >
> > On Mon, Jul 12, 2021 at 8:36 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >>
> >> >
> >> > 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.
> >
> >
> > Ok. I thought multiple errors are possible when many tables are initialized using parallel workers (with
max_sync_workers_per_subscription> 1).
> >
>
> Yeah, that is possible but that covers under the second condition
> mentioned by me and in such cases I think we should have separate rows
> for each tablesync. Is that right, Sawada-san or do you have something
> else in mind?
Yeah, I agree to have separate rows for each table sync. The table
should not be processed by both the table sync worker and the apply
worker at a time so the pair of subscription OID and relation OID will
be unique. I think that we have a boolean column in the view,
indicating whether the error entry is reported by the table sync
worker or the apply worker, or maybe we also can have the action
column show "TABLE SYNC" if the error is reported by the table sync
worker.
When it comes to removing the subscription errors in
pgstat_vacuum_stat(), I think we need to seq scan on the hash table
and send the messages to purge the subscription error entries.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/