Re: Failed transaction statistics to measure the logical replication progress

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.

> So it
> might be enough to have actual rollbacked transactions. If this value
> is high, it's likely that many rollbacked transactions are streamed,
> unnecessarily consuming network bandwidth. So the user might want to
> increase logical_decoding_work_mem to suppress transactions getting
> streamed.
>

Okay, we might want to probably document such a use case.

--
With Regards,
Amit Kapila.