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 1moJod-00024I-As for pgsql-hackers@arkaria.postgresql.org; Sat, 20 Nov 2021 06:25:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1moJob-00058L-5b for pgsql-hackers@arkaria.postgresql.org; Sat, 20 Nov 2021 06:25:33 +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 1moJoa-00058C-Q9 for pgsql-hackers@lists.postgresql.org; Sat, 20 Nov 2021 06:25:32 +0000 Received: from mail-yb1-xb33.google.com ([2607:f8b0:4864:20::b33]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1moJoY-0007xr-AC for pgsql-hackers@lists.postgresql.org; Sat, 20 Nov 2021 06:25:32 +0000 Received: by mail-yb1-xb33.google.com with SMTP id g17so34363868ybe.13 for ; Fri, 19 Nov 2021 22:25:29 -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:content-transfer-encoding; bh=A1ll9x+R0XvET4F9R6t/0RK5LfT6L5IO8il6VRciNCE=; b=O9X3LRAqfRB8bf6HeCDlx2AObNEHR5EQ2AiXQywo7bkVsm4VOVP19aDAl/X8XXBNwJ 4XlnRHJv0s1VPx45TqalGauRdRjz7ldVnEgWqCjG+T46IpXjvTzJxNjA+u5Nym8E5z5Z rzhtTWiHxu9N5PF3Ua7NT8fSVKiDNn2Ztu8yJBI/ZAmp1Y/E3mKGYjFPioaZIEnBJOsQ WTyOMXmSjYsRNw4/L8Nay7TYCfNqTjFloEyS/uzPA4TDPptaGI569wwQozV2zRZLfv7a 6rAsnWR5D7HNvenJ3vi7wNQ7a76uDItR0dptWJ/A/cgal51U1b77T9YsD80gqxEOWvHl O2OQ== 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:content-transfer-encoding; bh=A1ll9x+R0XvET4F9R6t/0RK5LfT6L5IO8il6VRciNCE=; b=aw3jxCJdN8eQuePZ0KCRL1KeIfMzFvePqNYhpxnHlzq7Sf6kYrvO/CTOlGqvg6Bdty 3e9MDzU8zcg+VutAhI1iRlfhMKDHVsBu3RwWLh89kTa2GIazd2RBSde08ubRE++Nfqv3 jMV+nTbWrxa0lsxInT0/ODR1p9pYkdK5NVffjOxqlGTxJn7CvzptOT+faQQECqe5zNQ2 KRlBBANy1NT21+zngHeyTdal9jsDCmrHiMRsCqDHPlJrMSSsCWZBfTulY7bB7WT30Zj3 cIPNb6wtPsXvfbM82yKUo25MjR7QVuZS8811HG2t9VDrcpKGnNtUH8FhZHseluZI14T2 Ye2g== X-Gm-Message-State: AOAM533MqwseNxdQOgpUt/8zX0Q/2Wq7zci0Yo8PaD6AFiV8sUaOz1+m hollISygj6Nv7uRbEVzUwASkl7wgOub5mTkmMGk= X-Google-Smtp-Source: ABdhPJwmitTAn8Vf35GyfZ639dGIKX+oLSEQW9e2d/ymkY95bnGsrSNruu62I2lB59Hrm39dko/Q4CkPXBc+yicNXJs= X-Received: by 2002:a5b:502:: with SMTP id o2mr40277231ybp.452.1637389528027; Fri, 19 Nov 2021 22:25:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Sat, 20 Nov 2021 11:55:16 +0530 Message-ID: Subject: Re: Failed transaction statistics to measure the logical replication progress To: Masahiko Sawada Cc: "osumi.takamichi@fujitsu.com" , vignesh C , Greg Nancarrow , "houzj.fnst@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 Fri, Nov 19, 2021 at 7:41 PM Masahiko Sawada wro= te: > > On Thu, Nov 18, 2021 at 12:26 PM Amit Kapila wr= ote: > > > > 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 pat= ch are > > > > better than the existing names proposed in Sawada-San's patch? Is i= t because > > > > those fields always contain the information of the last or latest e= rror 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 indic= ates > > > cumulative count of error to show all error counts that the worker go= t 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? > > > > I'm concerned that these new names will introduce confusion; if we > have last_error_relid, last_error_command, last_error_message, > last_error_time, and last_error_xid, I think users might think that > first_error_time is the timestamp at which an error occurred for the > first time in the subscription worker. > Isn't to some extent that confusion already exists because of last_error_time column? > Also, I'm not sure > last_error_count is not clear to me (it looks like showing something > count but the only "last" one?). > I feel if all the error related columns have "last_error_" as a prefix then it should not be that confusing? > An alternative idea would be to add > total_error_count by this patch, resulting in having both error_count > and total_error_count. Regarding commit_count and abort_count, I > personally think xact_commit and xact_rollback would be better since > they=E2=80=99re more consistent with pg_stat_database view, although we m= ight > already have discussed that. > Even if we decide to change the column names to xact_commit/xact_rollback, I think with additional non-error columns it will be clear to add 'error' in column names corresponding to error columns, and last_error_* seems to be consistent with what we have in pg_stat_archiver (last_failed_wal, last_failed_time). Your point related to first_error_time has merit and I don't have a better answer for it. I think it is just a convenience column and we are not sure whether that will be required in practice so maybe we can drop that column and come back to it later once we get some field feedback on this view? --=20 With Regards, Amit Kapila.