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

From osumi.takamichi@fujitsu.com
Subject RE: Failed transaction statistics to measure the logical replication progress
Date
Msg-id OSBPR01MB488836C2AC317994E3FE3AAEEDAB9@OSBPR01MB4888.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 Thursday, September 30, 2021 8:13 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Thu, Sep 30, 2021 at 1:02 PM Osumi, Takamichi/大墨 昂道
> <osumi.takamichi@fujitsu.com> wrote:
> >
> > On Thursday, September 30, 2021 1:15 PM Amit Kapila
> <amit.kapila16@gmail.com> wrote:
> > > On Thu, Sep 30, 2021 at 8:22 AM Hou, Zhijie/侯 志杰
> > > <houzj.fnst@fujitsu.com> wrote:
> > > >
> > > > On Tues, Sep 28, 2021 6:05 PM Amit Kapila
> > > > <amit.kapila16@gmail.com>
> > > wrote:
> > > > Adding a new view seems resonalble, but it will bring another
> > > > subscription related view which might be too much. OTOH, I can see
> > > > there are already some different views[1] including xact stat,
> > > > maybe adding
> > > another one is accepatble ?
> > > These all views are related to untransmitted to the collector but
> > > what we really need is a view similar to pg_stat_archiver or
> > > pg_stat_bgwriter which gives information about background workers.
> > > Now, the problem as I see is if we go that route then
> > > pg_stat_subscription will no longer remain dynamic view and one
> > > might consider that as a compatibility break. The other idea I have
> > > shared is that we display these stats under the new view introduced
> > > by Sawada-San's patch [1] and probably rename that view as
> > > pg_stat_subscription_worker where all the stats (xact info and last
> > > failure
> > > information) about each worker will be displayed.
> > Sorry, all the stats in pg_stat_subscription_worker view ?
> >
> > There was a discussion that
> > the xact info should be displayed from pg_stat_subscription with
> > existing stats in the same (which will be changed to persist), but
> > when your above proposal comes true, the list of
> > pg_stat_subscription_worker's columns will be something like below
> > (when I list up major columns).
> >
> > - subid, subrelid and some other relation attributes required
> > - 5 stats values moved from pg_stat_subscription
> >   received_lsn, last_msg_send_time, last_msg_receipt_time,
> >   latest_end_lsn, latest_end_time
> >
> 
> If we go with the view as pg_stat_subscription_worker, we don't need to move
> the existing stats of pg_stat_subscription into it.
Thank you for clarifying this point. I understand.


Best Regards,
    Takamichi Osumi


pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: non-superusers are allowed to drop the replication user, but are not allowed to alter or even create them, is that ok?
Next
From: Zhihong Yu
Date:
Subject: Re: Multi-Column List Partitioning