Re: Skipping logical replication transactions on subscriber side

On Sat, Oct 30, 2021 at 12:21 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Oct 29, 2021 at 4:49 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Oct 29, 2021 at 10:54 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> > > I'm not sure it's better to drop apply worker stats after resetting
> > > skip xid (i.g., after skipping the transaction). Since the view is a
> > > cumulative view and has last_error_time, I thought we can have the
> > > apply worker stats until the subscription gets dropped.
> > >
> >
> > Fair enough. So statistics can be removed either by vacuum or drop
> > subscription. Also, if we go by this logic then there is no harm in
> > retaining the stat entries for tablesync errors. Why have different
> > behavior for apply and tablesync workers?
> >
> > 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?
> >
>
> Don't we want these stats to be dealt in the same way as tables and
> functions as all the stats entries (subscription entries) are specific
> to a particular database? If so, I think we should write/read these
> to/from db specific stats file in the same way as we do for tables or
> functions. I think in the current patch, it will unnecessarily read
> and probably write subscription stats even when those are not
> required.

Good point! So probably we should have PgStat_StatDBEntry have the
hash table for subscription worker statistics, right?

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/