RE: Failed transaction statistics to measure the logical replication progress

From: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>
To: 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>
Cc: "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>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: RE: Failed transaction statistics to measure the logical replication progress
Date: 2021-10-01 14:52:24
Message-ID: OSBPR01MB488836C2AC317994E3FE3AAEEDAB9@OSBPR01MB4888.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, September 30, 2021 8:13 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Sep 30, 2021 at 1:02 PM Osumi, Takamichi/大墨 昂道
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> >
> > On Thursday, September 30, 2021 1:15 PM Amit Kapila
> <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > On Thu, Sep 30, 2021 at 8:22 AM Hou, Zhijie/侯 志杰
> > > <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > > >
> > > > On Tues, Sep 28, 2021 6:05 PM Amit Kapila
> > > > <amit(dot)kapila16(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2021-10-01 15:09:07 Re: Multi-Column List Partitioning
Previous Message Mark Dilger 2021-10-01 14:38:52 Re: non-superusers are allowed to drop the replication user, but are not allowed to alter or even create them, is that ok?