On Mon, Oct 18, 2021 at 7:03 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Oct 14, 2021 at 9:23 AM houzj.f...@fujitsu.com > <houzj.f...@fujitsu.com> wrote: > > > > On Thursday, September 30, 2021 12:15 PM Amit Kapila > > <amit.kapil...@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/
