Re: Skipping logical replication transactions on subscriber side

On Tue, Nov 2, 2021 at 2:17 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Tue, Nov 2, 2021 at 2:35 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> >
> > > >
> > > > I have another question in this regard. Currently, the reset function
> > > > seems to be resetting only the first stat entry for a subscription.
> > > > But can't we have multiple stat entries for a subscription considering
> > > > the view's cumulative nature?
> > >
> > > I might be missing your points but I think that with the current
> > > patch, the view has multiple entries for a subscription. That is,
> > > there is one apply worker stats and multiple table sync worker stats
> > > per subscription.
> > >
> >
> > Can't we have multiple entries for one apply worker?
>
> Umm, I think we have one stats entry per one logical replication
> worker (apply worker or table sync worker). Am I missing something?
>

No, you are right. I got confused.

> >
> > > And pg_stat_reset_subscription() function can reset
> > > any stats by specifying subscription OID and relation OID.
> > >
> >
> > Say, if the user has supplied just subscription OID then isn't it
> > better to reset all the error entries for that subscription?
>
> Agreed. So pg_stat_reset_subscription_worker(oid) removes all errors
> for the subscription whereas pg_stat_reset_subscription_worker(oid,
> null) reset only the apply worker error for the subscription?
>

Yes.

--
With Regards,
Amit Kapila.