On Mon, Feb 21, 2022 at 1:18 PM Andres Freund <and...@anarazel.de> wrote: > > On 2022-02-21 12:39:31 +0530, Amit Kapila wrote: > > Fair enough. Then, how about the following keeping the following > > information: > > Mostly sounds good. > > > > * subid (subscription id) > > * subname (subscription name) > > Coming from catalog, via join, I assume? >
The subname would be from pg_subscription catalog similar to what we are doing now for pg_stat_subscription_workers. > > > * sync_error_count/sync_failure_count (number of timed table sync failed) > > * apply_error_count/apply_failure_count (number of times apply failed) > > Yep. > > > > * sync_success_count (number of table syncs successfully finished) > > This one I'm not quite convinced by. You can't rely on precise counts with > pgstats and we should be able to get a better idea from somewhere more > permanent which relations succeeded? But it also doesn't do much harm, so ... > We can get precise information from pg_subscription_rel (rels that are in ready/finish_copy state) but OTOH, during refresh some of the rels would have been dropped or if a user creates/refreshes publication with copy_data = false, then we won't get information about how many table syncs succeeded? I have also kept this to make the sync information look consistent considering we have sync_failure_count. > > > * apply_commit_count (number of transactions applied successfully) > > * apply_rollback_count (number of transactions explicitly rolled back) > > What does "explicit" mean here? > It is for the Rollback Prepared case and probably for streaming of in-progress transactions that eventually get rolled back. > > > * stats_reset (Time at which these statistics were last reset) > > > > The view name could be pg_stat_subscription_lrep, > > pg_stat_logical_replication, or something on those lines. > > pg_stat_subscription_stats :) > Having *stat* two times in the name sounds slightly odd to me but let us see what others think. One more option could be pg_stat_subscription_replication. -- With Regards, Amit Kapila.
