On Mon, Feb 21, 2022 at 11:04 AM Andres Freund <and...@anarazel.de> wrote: > > On 2022-02-21 12:56:46 +0900, Masahiko Sawada wrote: > > > To take a precedent, we used to store accumulative statistics such as > > spill_txns to pg_stat_replication, but then for the same reason we moved > > those statistics to the new stats view, pg_stat_replication_slot. New > > subscription statistics that we're introducing are cumulative statistics > > whereas pg_stat_subscription is a dynamic statistics view. > > I'm happy to have cumulative subscriber stats somewhere in pgstats. But it > shouldn't be split by worker or relation, and it shouldn't contain > non-cumulative error information. >
Fair enough. Then, how about the following keeping the following information: * subid (subscription id) * subname (subscription name) * sync_error_count/sync_failure_count (number of timed table sync failed) * apply_error_count/apply_failure_count (number of times apply failed) * sync_success_count (number of table syncs successfully finished) * apply_commit_count (number of transactions applied successfully) * apply_rollback_count (number of transactions explicitly 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. -- With Regards, Amit Kapila.
