Re: Design of pg_stat_subscription_workers vs pgstats - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Design of pg_stat_subscription_workers vs pgstats
Date
Msg-id CAA4eK1J3dhfMRNQ6Q585nFr1vmXaTXVW9qv4hmUxLwDwJp-9RQ@mail.gmail.com
Whole thread Raw
In response to Re: Design of pg_stat_subscription_workers vs pgstats  (Andres Freund <andres@anarazel.de>)
Responses Re: Design of pg_stat_subscription_workers vs pgstats  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Design of pg_stat_subscription_workers vs pgstats  (Andres Freund <andres@anarazel.de>)
Re: Design of pg_stat_subscription_workers vs pgstats  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Mon, Feb 21, 2022 at 1:18 PM Andres Freund <andres@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.



pgsql-hackers by date:

Previous
From: Yura Sokolov
Date:
Subject: Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.
Next
From: Daniel Gustafsson
Date:
Subject: Re: Patch a potential memory leak in describeOneTableDetails()