Re: Failed transaction statistics to measure the logical replication progress

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: "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-08-04 12:58:38
Message-ID: CAA4eK1KMT8biciVqTBoZ9gYV-Gf297JFeNhJaxZNmFrZL8m2jA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 4, 2021 at 12:35 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Wed, Aug 4, 2021 at 12:17 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Wed, Aug 4, 2021 at 6:19 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> > > On Tue, Aug 3, 2021 at 6:11 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > >
> > > > I was trying to think based on similar counters in pg_stat_database
> > > > but if you think there is a value in showing errored and actual
> > > > rollbacked transactions separately then we can do that but how do you
> > > > think one can make use of it?
> > >
> > > I'm concerned that the value that includes both errored and actual
> > > rollbacked transactions doesn't make sense in practice since the
> > > number of errored transactions can easily get increased once a
> > > conflict happens. IMO the errored transaction doesn’t not necessarily
> > > necessary since the number of (successive) errors that happened on the
> > > subscription is tracked by pg_stat_subscription_errors view.
> > >
> >
> > It sounds awkward to display two of the xact (xact_commit,
> > xact_rollback) counters in one view and then the other similar counter
> > (xact_error or something like that) in another view. Isn't it better
> > to display all of them together possibly in pg_stat_subscription? I
> > guess it might be a bit tricky to track counters for tablesync workers
> > separately but we can track them in the corresponding subscription.
>
> I meant that the number of rolled back transactions due to an error
> seems not to be necessary since pg_stat_subscription_errors has a
> similar value.
>

I got that point.

> So what I imagined is that we have xact_commit and
> xact_rollback (counting only actual rollbacked transaction) counters
> in pg_stat_subscription. What do you think of this idea? Or did you
> mean the number of errored transactions also has value so should be
> included in pg_stat_subscription along with xact_commit and
> xact_rollback?
>

I meant the later one. I think it might be better to display all three
(xact_commit, xact_abort, xact_error) in one place. Earlier it made
sense to me to display it in pg_stat_subscription_errors but not sure
after this proposal. Won't it be better for users to see all the
counters in one view?

> Originally I thought your proposal of having the number of rollback
> transactions includes both errored transactions and actual rolled back
> transactions so my point was it's better to separate them and include
> only the actual rolled-back transaction.
>

I am fine with your proposal to separate the actual rollback and error
transactions counter but I thought it would be better to display them
in one view.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2021-08-04 13:26:26 Release 13.1 of the PostgreSQL BuildFarm client
Previous Message Amul Sul 2021-08-04 12:56:30 Re: [Patch] ALTER SYSTEM READ ONLY