Re: Failed transaction statistics to measure the logical replication progress

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Failed transaction statistics to measure the logical replication progress
Date: 2021-10-21 01:18:35
Message-ID: CAD21AoDF7LmSALzMfmPshRw_xFcRz3WvB-me8T2gO6Ht=3zL2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-10-21 02:42:31 Re: [PATCH] Fix memory corruption in pg_shdepend.c
Previous Message Greg Nancarrow 2021-10-20 23:10:57 Re: Added schema level support for publication.