Re: Failed transaction statistics to measure the logical replication progress

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Failed transaction statistics to measure the logical replication progress
Date: 2021-12-15 05:09:16
Message-ID: CAD21AoC8sFiDP2B+WrrJ8d15KRmHnvRkFLaF4YH4zMxCMG-4ug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 14, 2021 at 11:28 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Dec 13, 2021 at 5:48 PM osumi(dot)takamichi(at)fujitsu(dot)com
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> >
> > On Monday, December 13, 2021 6:19 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > On Tue, Dec 7, 2021 at 3:12 PM osumi(dot)takamichi(at)fujitsu(dot)com
> > > <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> > >
> > > Few questions and comments:
> > Thank you for your comments !
> >
> > > ========================
> > > 1.
> > > The <structname>pg_stat_subscription_workers</structname> view will
> > > contain
> > > one row per subscription worker on which errors have occurred, for workers
> > > applying logical replication changes and workers handling the initial data
> > > - copy of the subscribed tables. The statistics entry is removed when the
> > > - corresponding subscription is dropped.
> > > + copy of the subscribed tables. Also, the row corresponding to the apply
> > > + worker shows all transaction statistics of both types of workers on the
> > > + subscription. The statistics entry is removed when the corresponding
> > > + subscription is dropped.
> > >
> > > Why did you choose to show stats for both types of workers in one row?
> > This is because if we have hundreds or thousands of tables for table sync,
> > we need to create many entries to cover them and store the entries for all tables.
> >
>
> If we fear a large number of entries for such workers then won't it be
> better to show the value of these stats only for apply workers. I
> think normally the table sync workers perform only copy operation or
> maybe a fixed number of xacts, so, one might not be interested in the
> transaction stats of these workers. I find merging only specific stats
> of two different types of workers confusing.
>
> What do others think about this?

I understand the concern to have a large number of entries but I agree
that merging only specific stats would confuse users. As Amit
suggested, it'd be better to show only apply workers' transaction
stats.

Regards,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2021-12-15 05:47:51 Re: generalized conveyor belt storage
Previous Message Greg Nancarrow 2021-12-15 04:58:29 Re: Skipping logical replication transactions on subscriber side