Hi, 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? > * 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 ... > * apply_commit_count (number of transactions applied successfully) > * apply_rollback_count (number of transactions explicitly rolled back) What does "explicit" mean here? > * 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 :) (I really dislike that we have pg_stat_ stuff that's not actually stats, but something describing the current state, but that ship has well sailed). Greetings, Andres Freund
