On Mon, Jul 12, 2021 at 11:13 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Mon, Jul 12, 2021 at 1:15 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Mon, Jul 12, 2021 at 9:37 AM Alexey Lesovsky <lesov...@gmail.com> wrote: > > > > > > On Mon, Jul 12, 2021 at 8:36 AM Amit Kapila <amit.kapil...@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. >
Or similar to backend_type (text) in pg_stat_activity, we can have something like error_source (text) which will display apply worker or tablesync worker? I think if we have this column then even if there is a chance that both apply and sync worker operates on the same relation, we can identify it via this column. -- With Regards, Amit Kapila.
