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 1mnY47-0006oQ-RI for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Nov 2021 03:26: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 1mnY46-0001k5-IY for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Nov 2021 03:26: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 1mnY46-0001jw-7S for pgsql-hackers@lists.postgresql.org; Thu, 18 Nov 2021 03:26:22 +0000 Received: from mail-yb1-xb35.google.com ([2607:f8b0:4864:20::b35]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mnY43-0001Og-NY for pgsql-hackers@lists.postgresql.org; Thu, 18 Nov 2021 03:26:21 +0000 Received: by mail-yb1-xb35.google.com with SMTP id 131so13763080ybc.7 for ; Wed, 17 Nov 2021 19:26:19 -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=KZzUQs0fG0wXAsgavuB63hiTu2tlrglwcnSQUC2A/Pg=; b=AengTZWOAgPxlZD9aIDHBbaPlpasCDrUtyoITA49bocuUtXtUM8WZZeNKnYVKP+QuW 5xrbYV2DwBl4d6grAhYRsN33+BQnFJX4qJ8T4ya0DbxrL5amsf1+XuSdPSol4zB16TAS OrExwhKXXaAhT6WP6C8rViRK4VuJvRSmZEUJtCPpe2sWLmo09rZsK9kXDddiau0m7ZU1 JrILHMf3wubcbY0FlKBO/Iwoj3IhO6s5deSSFug8dpTn9jSJyvZ1Iycggozb9CNTf/Yf ExegJ0McTdnum/Kk1/U36m//cV/c8TMWFGaB942leiDNcdXxQwMXKBldUjHUz3FUemY3 336g== 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=KZzUQs0fG0wXAsgavuB63hiTu2tlrglwcnSQUC2A/Pg=; b=YQXVj37UgDznJKGCcsDTwS78rnX19+qmMLGUBSRUSHSyL4fZHvmMDBkb9rpSC6F2jJ IT+lculglQRGbznlywJoOobpd5qc1gkMxOMoIdHmqnbZhGo/42eUUcArihXwwZui2YoO /hasC9RuiRCR80F9my1usTc9rd3gNSRJs85WoF+zXabiQ/QsSrfcyEqnzEeVSkCozDBB nvsdAv+J4ZjIqu1NdB/LcSUXenE7AUqn86rRztL4/LPkhMhi4fAXpx6lmkqBDyluLFlt C09yTrzW6WIAYnDuPZBnGNEPMXI8LtsePqL4zpMKN0aJVeND5ndnpKmIH+zv2Dqnu7FJ lhpg== X-Gm-Message-State: AOAM531IJVEqRfM4BooVKSQkSRR/zbtnr/R3Dgr+d6gqivN74rqCLdR3 Ea8Czu8zIni3ED6zFAT7oY8Y3whbcZdSFBPtbcQ= X-Google-Smtp-Source: ABdhPJz+ElysZrEvn2clIudBLPdRVRQ0BQKnGxUxBMnf7Gk+pIf4Cv20qOWP+La8N3IK2gqmJ97BO4Cmn96sYhmhV5s= X-Received: by 2002:a25:90b:: with SMTP id 11mr23405891ybj.192.1637205978389; Wed, 17 Nov 2021 19:26:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Thu, 18 Nov 2021 08:56:07 +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 7:12 PM osumi.takamichi@fujitsu.com wrote: > > On Wednesday, November 17, 2021 10:00 PM Amit Kapila wrote: > > > > 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? > This is one reason. > > Another big reason comes from the final alignment when we list up all columns of both patches. > The patches in this thread is trying to introduce a column that indicates > cumulative count of error to show all error counts that the worker got in the past. > Okay, I see your point and it makes sense to rename columns after these other stats. I am not able to come up with any better names than what is being used here. Sawada-San, do you agree with this, or do let us know if you have any better ideas? BTW, I think the way you are computing error_count in pgstat_recv_subworker_error() doesn't seem correct to me because it will accumulate the counter/bytes for the same error again and again. You might want to update these counters after we have checked that the received error is not the same as the previous one. -- With Regards, Amit Kapila.