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 1mnKY3-0006Iz-S0 for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Nov 2021 13:00:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mnKY2-0001WH-Qx for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Nov 2021 13:00:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mnKY2-0001W8-GB for pgsql-hackers@lists.postgresql.org; Wed, 17 Nov 2021 13:00:22 +0000 Received: from mail-yb1-xb34.google.com ([2607:f8b0:4864:20::b34]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mnKXy-0002z5-9d for pgsql-hackers@lists.postgresql.org; Wed, 17 Nov 2021 13:00:21 +0000 Received: by mail-yb1-xb34.google.com with SMTP id e136so7339290ybc.4 for ; Wed, 17 Nov 2021 05:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p2CQ/+3/5Ljj0jUZash9EdJ7reWhVYoh7wTRx92rFJ8=; b=bRIwbmvaJc7oDYIIxj2FFDwCVu9bM7EO1E4bkAZk6NxeDN3xnWAmEJFB9lHrmgYAoy c+x09aJ4ywR7oyfy5lMuzKzv3lZn6Of6bNPOkvVu9DIWmWxIpBfhaQT9pQsiq3bwIDXZ 9sdRnf/AccLM9exUtHPrC7oQ5xMGwwTYPdiKwLL4HmLRt+CT9erF2TqPMzahHUjR5szN Yrx4AQnCHHxYg270lcqMq1eocGCsUnSkOwJhCOm/H4p7kS0Y/rt+4hOXMZkseV1QsdSE ure2sOpZ9/264sfgGy5LL+nn/bqpIN2L6E7d+O0IHLgQFEcIy+9KmAQy79lwkDEVUY+J KNsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p2CQ/+3/5Ljj0jUZash9EdJ7reWhVYoh7wTRx92rFJ8=; b=QzpnXXOy/0PUdv2oXO6ujci3fXzL8YS/b8O239owfn0ZQ5t2xBbbkZXAA1sbxlCJbj 8vBtA11mwrWQujRb3esGznPffV8BFWvQy1Wy1mCC8qzOuNQrFvuRSBRoBGp/FwjnAK2/ 16OWr8xmIIjLlNgjCYC+lGWqJslxofP1KkRYzyBwJafsLrh14C2b3HEU/GlPVggZ0zvx g5JeVBVZP3T+P9Sqw9mF9aWFjIf7XiaZWmNC0qmE91aUrsi8NEcJv9thhypCmopAjnlj wClywgtYNlte4aUPCGCfa5sum/AqdXMCVPgYjKf1CKvXaTKvBtnsA9liDOYlZIGKQRLU W7tA== X-Gm-Message-State: AOAM531s4SjABM6v9O2n72n4qrK7GKyawZvp6xPIbRiq+lG78IMUZVt6 xM12rFEtudG2fE2kiBFIkeu3wtzwWtkQZtYVRP4= X-Google-Smtp-Source: ABdhPJzmmUX+R3iP+e1VhDwn/6zlgDS0fnMZwgjeIMOZfHo/0JLD5vTJvJ9LT6cIKuCueOty1ST8gcKME6AhioKSRLs= X-Received: by 2002:a25:4bc3:: with SMTP id y186mr15993985yba.74.1637154015662; Wed, 17 Nov 2021 05:00:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Wed, 17 Nov 2021 18:30:04 +0530 Message-ID: Subject: Re: Failed transaction statistics to measure the logical replication progress To: "osumi.takamichi@fujitsu.com" Cc: Masahiko Sawada , vignesh C , Greg Nancarrow , "houzj.fnst@fujitsu.com" , "pgsql-hackers@lists.postgresql.org" Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Nov 17, 2021 at 9:44 AM osumi.takamichi@fujitsu.com wrote: > > On Wednesday, November 17, 2021 12:19 PM Masahiko Sawada wrote: > > On Tue, Nov 16, 2021 at 9:34 PM osumi.takamichi@fujitsu.com > > wrote: > > > > > > On Monday, November 15, 2021 9:14 PM I wrote: > > > > I've conducted some update for this. > > > > (The rebased part is only C code and checked by pgindent) > > > I'll update my patches since a new skip xid patch has been shared in > > > [1]. > > > > > > This version includes some minor renames of functions that are related > > > to transaction sizes. > > > > I've looked at v12-0001 patch. Here are some comments: > Thank you for paying attention to this thread ! > > > > - TupleDescInitEntry(tupdesc, (AttrNumber) 3, "relid", > > + TupleDescInitEntry(tupdesc, (AttrNumber) 3, "last_error_relid", > > OIDOID, -1, 0); > > - TupleDescInitEntry(tupdesc, (AttrNumber) 4, "command", > > + TupleDescInitEntry(tupdesc, (AttrNumber) 4, "last_error_command", > > TEXTOID, -1, 0); > > - TupleDescInitEntry(tupdesc, (AttrNumber) 5, "xid", > > + TupleDescInitEntry(tupdesc, (AttrNumber) 5, "last_error_xid", > > XIDOID, -1, 0); > > - TupleDescInitEntry(tupdesc, (AttrNumber) 6, "error_count", > > + TupleDescInitEntry(tupdesc, (AttrNumber) 6, "last_error_count", > > INT8OID, -1, 0); > > - TupleDescInitEntry(tupdesc, (AttrNumber) 7, "error_message", > > + TupleDescInitEntry(tupdesc, (AttrNumber) 7, "last_error_message", > > > > If renaming column names clarifies those meanings, the above changes should > > be included into my patch that introduces pg_stat_subscription_workers > > view? Right. > At first, your column names of pg_stat_subscription_workers look totally OK to me by itself > and I thought I should take care of those renaming at the commit timing of my stats patches. > Can you please tell us why you think the names in your proposed patch are better than the existing names proposed in Sawada-San's patch? Is it because those fields always contain the information of the last or latest error that occurred in the corresponding subscription worker? If so, I am not very sure if that is a good reason to increase the length of most of the column names but if you and others feel that is helpful then it is better to do it as part of Sawada-San's patch. -- With Regards, Amit Kapila.