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 1mdMjs-0002kb-5e for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Oct 2021 01:19:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mdMjp-0004og-Pp for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Oct 2021 01:19:21 +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 1mdMjp-0004oX-FA for pgsql-hackers@lists.postgresql.org; Thu, 21 Oct 2021 01:19:21 +0000 Received: from mail-pj1-x1031.google.com ([2607:f8b0:4864:20::1031]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mdMji-0005L6-Ie for pgsql-hackers@lists.postgresql.org; Thu, 21 Oct 2021 01:19:21 +0000 Received: by mail-pj1-x1031.google.com with SMTP id u6-20020a17090a3fc600b001a00250584aso1874833pjm.4 for ; Wed, 20 Oct 2021 18:19:14 -0700 (PDT) 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=rhAfJjmY3bzXvyniE1MJa4orSlP5al0JS9Ic74PxRD4=; b=GLpIzT/GsMiLbmFPkg6slWW8X07KVhPSErHcGJWqhC749yChbabNLmUvuIUHT6HOfe SXt1V3L+vAw3ZpXCyr/HwBorjjydadBbKQbhHlbPTjg+RdT//RoTCUWFQCvQdSX28+6V MIDw2D7McAXDvAO7t5vbgFhXD46C/FTb73QtqpYaRIDkBbKl8EHHSIaOHIgXF/xOyRf2 qwbgq/VzeAaxX0FIT96ywtpIIGTHjb1V59isEb7Oq82/ZHoowD/MFgnf4NwjWGDdZEVc MxMLSS267qK8ppPVt4m5NiAXQY/nG51bsp1xmxnQeo3typWNkpsgetv/GN870RKFgh0I CNkg== 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=rhAfJjmY3bzXvyniE1MJa4orSlP5al0JS9Ic74PxRD4=; b=gplltPYiSpeFyHCEoUk1M/aYp77b20PpG84covhXUjz3Etit8JNL0P2gFo2JV2brOI BqfTBslQRmNEZMDhfCVagOcUPRvScXMyX17cB9Y/Mcgr50XtiUagpqEhQ/TcpYx2qOWF 4mxG8XVQsONwQh1Gr2fuwAZHaA86EWBJIdzwF4DnMeqQ+rfeFFAmtkuPsvyCNwA26a1B idp3C9MYjknXZfy8Zb6z5Jg8NfQ6qqxXXIRoM78VDK6U73p+q4nHpkGkvEJ0fqew8HIQ m4VJ8QbqPyochYPbJjOQF9g6mXl7CAodFANZh0tE9TYNRtpU/51QI08KL7ExTTG2nCKC 6tUQ== X-Gm-Message-State: AOAM530FxIR9LDFGULMryT/X5g2ejG7hZ0c8b8N45segjqpUc103x9oK TGXKCvOGQ2aVYO/dfUdwQWwaRpxlh/O6rksIWnM= X-Google-Smtp-Source: ABdhPJyKaPZMkmjAxj4NsCPYLA2P7BxCNfFcmwlYE5Ju248sJ9HD1i2lgwuBfSw/a3LY+krpZlGMvLKANmw6Zo4FGOQ= X-Received: by 2002:a17:90a:9291:: with SMTP id n17mr2719548pjo.243.1634779152106; Wed, 20 Oct 2021 18:19:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masahiko Sawada Date: Thu, 21 Oct 2021 10:18:35 +0900 Message-ID: Subject: Re: Failed transaction statistics to measure the logical replication progress To: Amit Kapila Cc: "houzj.fnst@fujitsu.com" , "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 Mon, Oct 18, 2021 at 7:03 PM Amit Kapila wrote= : > > On Thu, Oct 14, 2021 at 9:23 AM houzj.fnst@fujitsu.com > wrote: > > > > On Thursday, September 30, 2021 12:15 PM Amit Kapila > > > > > > These all views are related to untransmitted to the collector but wha= t > > > we really need is a view similar to pg_stat_archiver or > > > pg_stat_bgwriter which gives information about background workers. > > > Now, the problem as I see is if we go that route then > > > pg_stat_subscription will no longer remain dynamic view and one might > > > consider that as a compatibility break. The other idea I have shared > > > is that we display these stats under the new view introduced by > > > Sawada-San's patch [1] and probably rename that view as > > > pg_stat_subscription_worker where all the stats (xact info and last > > > failure information) about each worker will be displayed. Do you have > > > any opinion on that idea or do you see any problem with it? > > > > Personally, I think it seems reasonable to merge the xact stat into the= view from > > sawada-san's patch. > > > > One problem I noticed is that pg_stat_subscription_error > > currently have a 'count' column which show how many times the last erro= r > > happened. The xact stat here also have a similar value 'xact_error'. I = think we > > might need to rename it or merge them into one in some way. > > > > Besides, if we decide to merge xact stat into pg_stat_subscription_erro= r, some column > > seems need to be renamed. Maybe like: > > error_message =3D> Last_error_message, command=3D> last_error_command.. > > > > Don't you think that keeping the view name as > pg_stat_subscription_error would be a bit confusing if it has to > display xact_info? Isn't it better to change it to > pg_stat_subscription_worker or some other worker-specific generic > name? I agree that it'd be better to include xact info to pg_stat_subscription_errors view rather than making pg_stat_subscription a cumulative view. It would be more simple and consistent. The user might want to reset only either error stats or xact stats but we can do that by passing a value to the reset function. For example, pg_stat_reset_subscription_worker(10, 20, =E2=80=98error') for resetting on= ly error stats whereas pg_stat_reset_subscription_worker(10, 20, =E2=80=98xact= =E2=80=99) for resetting only xact stats etc (passing NULL or omitting the third argument means resetting all stats). I'll change the view name in the next version patch. Regards, --=20 Masahiko Sawada EDB: https://www.enterprisedb.com/