RE: Failed transaction statistics to measure the logical replication progress

Поиск
Список
Период
Сортировка
От houzj.fnst@fujitsu.com
Тема RE: Failed transaction statistics to measure the logical replication progress
Дата
Msg-id OS0PR01MB5716FE0CB26F1F4647921D7094759@OS0PR01MB5716.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Failed transaction statistics to measure the logical replication progress  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Ashutosh Sharma
Дата:
Сообщение: Re: Add sub-transaction overflow status in pg_stat_activity
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?