RE: Failed transaction statistics to measure the logical replication progress - Mailing list pgsql-hackers

From houzj.fnst@fujitsu.com
Subject RE: Failed transaction statistics to measure the logical replication progress
Date
Msg-id OS0PR01MB5716FE0CB26F1F4647921D7094759@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Failed transaction statistics to measure the logical replication progress  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tues, Dec 14, 2021 10:28 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Dec 13, 2021 at 5:48 PM osumi.takamichi@fujitsu.com
> <osumi.takamichi@fujitsu.com> wrote:
> >
> > On Monday, December 13, 2021 6:19 PM Amit Kapila
> <amit.kapila16@gmail.com> wrote:
> > > On Tue, Dec 7, 2021 at 3:12 PM osumi.takamichi@fujitsu.com
> > > <osumi.takamichi@fujitsu.com> wrote:
> > >
> > > Few questions and comments:
> > Thank you for your comments !
> >
> > > ========================
> > > 1.
> > >     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 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?

Personally, I agreed that merging two types of stats into one row might not be
a good idea. And the xact stats of table sync workers are usually less
interesting than the apply worker's, So, it's seems acceptable to me if we
show stats only for apply workers and document about this.

Best regards,
Hou zj

pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: Add sub-transaction overflow status in pg_stat_activity
Next
From: Bharath Rupireddy
Date:
Subject: Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?