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 1ngJ78-0006gg-IY for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Apr 2022 04:35:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ngJ77-0004uU-Ab for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Apr 2022 04:35:49 +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 1ngJ76-0004tZ-Vi for pgsql-hackers@lists.postgresql.org; Mon, 18 Apr 2022 04:35:49 +0000 Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ngJ72-0000hT-T7 for pgsql-hackers@lists.postgresql.org; Mon, 18 Apr 2022 04:35:47 +0000 Received: by mail-pg1-x52a.google.com with SMTP id h5so16758401pgc.7 for ; Sun, 17 Apr 2022 21:35:44 -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=cCRTeRO5zjhAEXIkNJma7YLCVqS9X5wtcQ7xy59Dy8M=; b=GYPqoblWnv8N3O9wlrdLxmnHQcGSh0tOW2G22X35t88mTYqNppeD+C9MRTjlNgo+jt Qm+Do9ZDX4zG7CgQvTz3/5ZtY9ZDt9upWmDKKbRbTnH4NWCMW04lpMmWaXnPdbC16spO L4ghi/pQTOXICzcx1pZesZg+S5qt1NdrxsYQGCkxVuGojYEjGr1CALO4aKMUXwKg+JJm MO56whaoj9StjTINWpB36KKnOtgaxDFN1fLBy0eRy//LHGzn52ZrP1wilJAnBRZBUCBu VpCT5jyQpZGV7Yr9B+RQKGc+USlBcdyg0kniYVdewHQnVJ96vsdwoeO91zDw8c3Ja7YY WGJA== 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=cCRTeRO5zjhAEXIkNJma7YLCVqS9X5wtcQ7xy59Dy8M=; b=yk5gD2x5rTgX6oWcTk8+ypKKwFOg2jio7qlWQVlyHYvIALa3LYhtLcMb6blMaAsdop S0BKAnryDYXSL1PxJtDX7hGq5WbM9o4rhJJAfG1VHC/lkFR0ILkT/jWa4YSIqK8C/YZH uA9hNBDRly0SCPkuNmznjrT+3/w8tl+VCrFFNsw3QE05aFX5R0ncyFS/W1Ss1JoFgHfQ VGI9NJqi7RKtwAeUjBKwwRd4d4rNHXOkoUcV5MBo0g2MSIx3L/WVK94YjcmJ3cs6of92 iFYYNWmG0Fpkq3WaAHbCVJ3qpx6ggklyn5mZFrkkBUECzihXXk/8u56U4WZ7ztPYPnFs VYUA== X-Gm-Message-State: AOAM532LAMUvH56sy/cDzkfeSQ4zkseTsLQUNxELUnlZCw6FaVYzugzt Odoo/eD/6nUnA4+fIcDAoUM+pU7SWoEfpF6OHko= X-Google-Smtp-Source: ABdhPJz1E7CjRHx3NKdWb9lu7yolWjx7EJ3etAG5N3peAiUnI8KBCdMM7PzmjVJ+FrbUqyN+ynieGCL01F5IiGcMyPQ= X-Received: by 2002:a05:6a00:140e:b0:4e1:c81a:625c with SMTP id l14-20020a056a00140e00b004e1c81a625cmr10281192pfu.39.1650256543801; Sun, 17 Apr 2022 21:35:43 -0700 (PDT) MIME-Version: 1.0 References: <0271e197-2cfe-4627-9c11-47535cc7fdf3@www.fastmail.com> <8cc4f31f-240a-4590-94a8-a50bdf4f4d1c@www.fastmail.com> In-Reply-To: From: Masahiko Sawada Date: Mon, 18 Apr 2022 13:35:07 +0900 Message-ID: Subject: Re: Logical replication timeout problem To: Amit Kapila Cc: "wangw.fnst@fujitsu.com" , Euler Taveira , "kuroda.hayato@fujitsu.com" , Peter Smith , Fabrice Chapuis , Simon Riggs , Petr Jelinek , "tanghy.fnst@fujitsu.com" , PostgreSQL Hackers , Ajin Cherian Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Apr 18, 2022 at 1:01 PM Amit Kapila wrote: > > On Thu, Apr 14, 2022 at 5:50 PM Masahiko Sawada wrote: > > > > On Wed, Apr 13, 2022 at 7:45 PM Amit Kapila wrote: > > > > > > On Mon, Apr 11, 2022 at 12:09 PM wangw.fnst@fujitsu.com > > > wrote: > > > > > > > > So I skip tracking lag during a transaction just like the current HEAD. > > > > Attach the new patch. > > > > > > > > > > Thanks, please find the updated patch where I have slightly modified > > > the comments. > > > > > > Sawada-San, Euler, do you have any opinion on this approach? I > > > personally still prefer the approach implemented in v10 [1] especially > > > due to the latest finding by Wang-San that we can't update the > > > lag-tracker apart from when it is invoked at the transaction end. > > > However, I am fine if we like this approach more. > > > > Thank you for updating the patch. > > > > The current patch looks much better than v10 which requires to call to > > update_progress() every path. > > > > Regarding v15 patch, I'm concerned a bit that the new function name, > > update_progress(), is too generic. How about > > update_replation_progress() or something more specific name? > > > > Do you intend to say update_replication_progress()? The word > 'replation' doesn't make sense to me. I am fine with this suggestion. Yeah, that was a typo. I meant update_replication_progress(). Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/