On Wed, Aug 4, 2021 at 6:19 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Tue, Aug 3, 2021 at 6:11 PM Amit Kapila <amit.kapil...@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. > 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.
