RE: Failed transaction statistics to measure the logical replication progress

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
- xact stats
xact_commit, xact_commit_bytes,
xact_error, xact_error_bytes,
xact_abort, xact_abort_bytes,
- error stats
datname, command, xid, failure_source,
failure_count, last_failure, last_failure_message, etc

If this is what you imagined,
what we can do from left values of pg_stat_subscription
would be only finding subscription worker's process id.
Is it OK and is this view's alignment acceptable ?

Best Regards,
Takamichi Osumi