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 1mVm7R-0002uz-6m for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Sep 2021 02:48:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mVm7P-00029T-Dl for pgsql-hackers@arkaria.postgresql.org; Thu, 30 Sep 2021 02:48:19 +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 1mVm7P-00029K-5o for pgsql-hackers@lists.postgresql.org; Thu, 30 Sep 2021 02:48:19 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mVm7M-0000t3-GN for pgsql-hackers@lists.postgresql.org; Thu, 30 Sep 2021 02:48:18 +0000 Received: by mail-pj1-x102c.google.com with SMTP id il14-20020a17090b164e00b0019c7a7c362dso943638pjb.0 for ; Wed, 29 Sep 2021 19:48:16 -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; bh=2vDA9Nwd/WNaPyrdj06Rx7M8cMigJo/r0BnCzczFtsw=; b=Pq0MQDPqTuBdOuwYZ81x8T7hgJMEc3u/H4A9bcuAYKLUi3fOH/F7CfK8lLbH/2SedR 8bwIlRD92/WwrZWRdd6zg3FS8iMHSf/Nbvu1ViCOeYAijCVviZ7Tm8FP2iNZFerXDMd+ 06otcjrziX4vbtyfWZSPDowoNQ6hOdFju38iw3RCgrtcjnjpKblpDeVQrwF66K3rRC/1 21+VVmBPuVNxFvagprDdiIAXNtCfQiqHAuNG1+85TFK/cuz2jhadXW8rSd4B11pbKMqd i4z2EDjCiL/Xyz7wyLNoy77PW9jwqHlLhcpRFfoXkohK6KjgmXSA9iKaxzhAeT9IfhMk pNlg== 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=2vDA9Nwd/WNaPyrdj06Rx7M8cMigJo/r0BnCzczFtsw=; b=Tl2Ic6BzmcLkVWU2NnciF1VGWRRXvegPThxadFCu4Fb0B22IvJ8n0jOEXhHfzmSbgn 1fIsrzUBQu3ZI2OyywzkCuSNcUFFIrhAWz7y3xAbgCU/vagk91GR/jrBvdo2KlQ+ovzO wfzXGc+h3mlNf/cUBFHX7jVS2RWcZTKVYuC3tGrD+wYZlKtJj4x7PIwA8LmX/gnmznJu LnFb7rz4rm5KPW8Xrp6fL/uINc0N2TryYFTJzzDk3XUtD5n9FdueGGoiZKdYIyXyuKzX OjN3pK5l3aDFRS8ZgSjy9Pdg+YMrOn1Zk+ntAAG1/99lLP0VTCzM0L0bGKqRMkDiRet2 uNLg== X-Gm-Message-State: AOAM532HMANX/eijS5gtRnq9eJk+8rJTmGmsGE3WQhdG/OTZ/EEy1C7g U1cbAAgwgpK8RKFSLw5RZ+jedLO7v3vyolxUNTA= X-Google-Smtp-Source: ABdhPJxuvOjGudhOV/xXNM6s3mB5/vF+Hy9iwiw0oyC2wCp0VjIJZE40VPQdTdwKdslaoMKg46xdpB/arvps+pxVrfY= X-Received: by 2002:a17:902:8a97:b0:13e:6e77:af59 with SMTP id p23-20020a1709028a9700b0013e6e77af59mr591628plo.4.1632970094430; Wed, 29 Sep 2021 19:48:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masahiko Sawada Date: Thu, 30 Sep 2021 11:47:38 +0900 Message-ID: Subject: Re: Failed transaction statistics to measure the logical replication progress To: Amit Kapila Cc: "osumi.takamichi@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, Sep 29, 2021 at 8:55 PM Amit Kapila wrote: > > On Wed, Sep 29, 2021 at 4:49 PM Masahiko Sawada wrote: > > > > On Tue, Sep 28, 2021 at 7:04 PM Amit Kapila wrote: > > > > > > On Tue, Sep 28, 2021 at 11:35 AM Masahiko Sawada wrote: > > > > > > > > On Tue, Sep 28, 2021 at 1:54 PM Amit Kapila wrote: > > > > > > > > > > > > > > > > > Then, if, we proceed in this direction, > > > > > > the place to implement those stats > > > > > > would be on the LogicalRepWorker struct, instead ? > > > > > > > > > > > > > > > > Or, we can make existing stats persistent and then add these stats on > > > > > top of it. Sawada-San, do you have any thoughts on this matter? > > > > > > > > I think that making existing stats including received_lsn and > > > > last_msg_receipt_time persistent by using stats collector could cause > > > > massive reporting messages. We can report these messages with a > > > > certain interval to reduce the amount of messages but we will end up > > > > seeing old stats on the view. > > > > > > > > > > Can't we keep the current and new stats both in-memory and persist on > > > disk? So, the persistent stats data will be used to fill the in-memory > > > counters after restarting of workers, otherwise, we will always refer > > > to in-memory values. > > > > Interesting. Probably we can have apply workers and table sync workers > > send their statistics to the stats collector at exit (before the stats > > collector shutting down)? And the startup process will restore them at > > restart? > > > > I think we do need to send at the exit but we should probably send at > some other regular interval as well to avoid losing all the stats > after the crash-restart situation. But we clear all statistics collected by the stats collector during crash recovery. No? Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/