Re: Failed transaction statistics to measure the logical replication progress

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. 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?

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.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/