Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBGU4-00024o-2Q for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Aug 2021 12:58:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mBGU2-00064I-Vy for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Aug 2021 12:58:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBGU2-00062f-O5 for pgsql-hackers@lists.postgresql.org; Wed, 04 Aug 2021 12:58:54 +0000 Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mBGU0-00075y-MD for pgsql-hackers@lists.postgresql.org; Wed, 04 Aug 2021 12:58:54 +0000 Received: by mail-yb1-xb31.google.com with SMTP id z128so3804475ybc.10 for ; Wed, 04 Aug 2021 05:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1KY741b/aGriMeElQ7ImIBicfZbrmxQnoxZtqh081fk=; b=bh4GrBoLv9zf2UKGdZsuFRURGBmrRx9Ut8VelioOMF+6Hnk8bZH2i9jVkPOCuVd2Ez qBopOyhLQyGyCHV8hbp36aoFIpscpHKhQfsrrnQfamOdaCOCZc+nFnJewV7DJlJVfFOz 3QDU1n6Zcclb7zpwfZCqpRjc06tYworxMl09jmLsS7Zp+LjJ4xMVqC+I3u3MJcUVXxA+ UbyX4SfZUX31tSN2/7gXL+TDo7ddNLn6gxeEPEn2nJcEBSOvyTUfrmCVJeiTQLzqVToS HxWxprrq+BKLBeIVoNoOnWtiK/JFgCyn7ZUAlxOse6F1R9h6393wAAavLYuB+IAN2xlh +1GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1KY741b/aGriMeElQ7ImIBicfZbrmxQnoxZtqh081fk=; b=HjBXAuBmDq8mGj1QFjDADlo0qaKk0s2NJCz06sFGNL6cS+HcSu78EUdd7yxbqf9FZz V7KqSw/h/h5S0wjiOBpFKYB/7nLigJyke0ez4ZxA/ceA1R51GEdsG98u3iLO+8EMQ7YE 0B6zVsFAztdkVHonowEOLY2FwFXyz3hd91XJzy/7aNoVwFW/tzHcI0hiz1LKKKFJIiMs oqBvsT4BTl0HkrsbhOiTBmzUrZDXaR/PaVnnm+NwSEoPO5i6dElmPWImWAWc82ZdNu2e hY5PrgdnsbuEYAUAPlEa397AlRmJ85xUqoiq0PUYmEkIttaMlIzKGG6jvQ3+Og+NdbEP H3VA== X-Gm-Message-State: AOAM531WmdmioBTKES6h85XzqLKv4mub5fTxMkao6B71NEZbqXDeXir5 FAFmXE29BIgsj8O4U9AFLCIOnKJa2OeKN4vbpn0= X-Google-Smtp-Source: ABdhPJzpy6H15qy0TiMsEnm4ZWM2YbWTzw/M7VX9Z6K38dWg0u2u+/RiCZme1k6pykSOYvzuQ8Ey/y5O7vJCsiXyl7w= X-Received: by 2002:a25:2593:: with SMTP id l141mr35300012ybl.489.1628081930571; Wed, 04 Aug 2021 05:58:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Wed, 4 Aug 2021 18:28:38 +0530 Message-ID: Subject: Re: Failed transaction statistics to measure the logical replication progress To: Masahiko Sawada Cc: "osumi.takamichi@fujitsu.com" , "pgsql-hackers@lists.postgresql.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Aug 4, 2021 at 12:35 PM Masahiko Sawada wro= te: > > On Wed, Aug 4, 2021 at 12:17 PM Amit Kapila wro= te: > > > > On Wed, Aug 4, 2021 at 6:19 AM Masahiko Sawada = wrote: > > > > > > On Tue, Aug 3, 2021 at 6:11 PM Amit Kapila = 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 y= ou > > > > 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=E2=80=99t not nec= essarily > > > necessary since the number of (successive) errors that happened on th= e > > > 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. --=20 With Regards, Amit Kapila.