Re: Failed transaction statistics to measure the logical replication progress - Mailing list pgsql-hackers
From | Amit Kapila |
---|---|
Subject | Re: Failed transaction statistics to measure the logical replication progress |
Date | |
Msg-id | CAA4eK1KMT8biciVqTBoZ9gYV-Gf297JFeNhJaxZNmFrZL8m2jA@mail.gmail.com Whole thread Raw |
In response to | Re: Failed transaction statistics to measure the logical replication progress (Masahiko Sawada <sawada.mshk@gmail.com>) |
Responses |
RE: Failed transaction statistics to measure the logical replication progress
|
List | pgsql-hackers |
On Wed, Aug 4, 2021 at 12:35 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Wed, Aug 4, 2021 at 12:17 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Wed, Aug 4, 2021 at 6:19 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > On Tue, Aug 3, 2021 at 6:11 PM Amit Kapila <amit.kapila16@gmail.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.
pgsql-hackers by date: