On Mon, Oct 18, 2021 at 7:03 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Oct 14, 2021 at 9:23 AM houzj.fnst@fujitsu.com
> <houzj.fnst@fujitsu.com> wrote:
> >
> > On Thursday, September 30, 2021 12:15 PM Amit Kapila <amit.kapila16@gmail.com>
> > >
> > > 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. Do you have
> > > any opinion on that idea or do you see any problem with it?
> >
> > Personally, I think it seems reasonable to merge the xact stat into the view from
> > sawada-san's patch.
> >
> > One problem I noticed is that pg_stat_subscription_error
> > currently have a 'count' column which show how many times the last error
> > happened. The xact stat here also have a similar value 'xact_error'. I think we
> > might need to rename it or merge them into one in some way.
> >
> > Besides, if we decide to merge xact stat into pg_stat_subscription_error, some column
> > seems need to be renamed. Maybe like:
> > error_message => Last_error_message, command=> last_error_command..
> >
>
> Don't you think that keeping the view name as
> pg_stat_subscription_error would be a bit confusing if it has to
> display xact_info? Isn't it better to change it to
> pg_stat_subscription_worker or some other worker-specific generic
> name?
I agree that it'd be better to include xact info to
pg_stat_subscription_errors view rather than making
pg_stat_subscription a cumulative view. It would be more simple and
consistent.
The user might want to reset only either error stats or xact stats but
we can do that by passing a value to the reset function. For example,
pg_stat_reset_subscription_worker(10, 20, ‘error') for resetting only
error stats whereas pg_stat_reset_subscription_worker(10, 20, ‘xact’)
for resetting only xact stats etc (passing NULL or omitting the third
argument means resetting all stats). I'll change the view name in the
next version patch.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
