Re: Failed transaction statistics to measure the logical replication progress

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. There is a
clear difference between them, all the stats displayed via
pg_stat_subscription are dynamic and won't persist whereas all the
stats corresponding to pg_stat_subscription_worker view will persist.


--
With Regards,
Amit Kapila.