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 1pIUtV-0008U6-Ka for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Jan 2023 13:23:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pIUtU-0002un-GB for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Jan 2023 13:23:52 +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 1pIUtU-0002ue-58 for pgsql-hackers@lists.postgresql.org; Thu, 19 Jan 2023 13:23:52 +0000 Received: from mail-oa1-x2a.google.com ([2001:4860:4864:20::2a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pIUtS-0004XK-6V for pgsql-hackers@postgresql.org; Thu, 19 Jan 2023 13:23:51 +0000 Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-1322d768ba7so2490067fac.5 for ; Thu, 19 Jan 2023 05:23:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZtYu1AK8nbESTFIW6bQMp5BXcVoxqv7LrPMa0Wp8NVc=; b=CN+vqEgDdVmxWHcQH6l8EVJr9vO3PEOb6bTOFTQfVbzH5BLdOcrizgE9IljL9/6s5f HIhmTKDZbElsAxgIWweqNTkKnNm1kcAbXjc4xoT+GmxSVu2sTBNLnrfF4LnsPZKXyeki 6rDI2ageQnh6oOsHegsL3h4N1RkmTQiciK5SBwBX2wYNHIubO7blUlCDCbIVfhCV8pii NLvOG4p3Ud3OPpUqyBCt+5DmPHsYdMu0rotTg3kdN5Q2yMGkbMAsKSmvc5ii2qcJfBWh Z6P9IqNXg//nRTH/OwCj0pVEnaQgiXAY/rNE2Hcd5JFee0PmySgCAbQvUUKey97nBxgx AxWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZtYu1AK8nbESTFIW6bQMp5BXcVoxqv7LrPMa0Wp8NVc=; b=3SLUQ5N63wsF8rJGbEopRhZ+pLk3K2mK5UHzRACy7H2gVfCXgzErTIE7b1m8jSnu+S ZPCT+55J2eO8eUUqHsdcB42KRViFbjxK7dX/BJpTo1kEQ1kDQ7Nk6EtU8Y6qN9hmLh+L C+cOWhgT4ulv90Jh+2rCdfgVN/BdnSKokxyrLoB91jpW4ZI6oPd89tlzU+GT/gkS642e ZhPD1KTScfKkJQoCuCr687LR6kAcJz7ZasOpqaLKVCxqmoHm9oEkKHycYH3S4+11pG7X sbgQ+xeki1Dexb7kVu3UmMALpRHvOX4frLU6uBXwNE8zcWR3QWxIAdTWUzOk8NON7fsK Nyiw== X-Gm-Message-State: AFqh2krTm7PoqjwQWMsM99Fp4znlDkGDPAoyJJjUu0vYPAOVwiomUkxr cLvFy7MuWdU7Y+JN1TzI7sRbbiaTYA/PeN/hMGE= X-Google-Smtp-Source: AMrXdXsET5KiQlgeTAzVQnVUDDbUfK3+QvOhHDRVPrl26v5jxuYDQbLx0YpDzPOi2SpmPTbda2aaggp1WcmYvwHllV8= X-Received: by 2002:a05:6870:5154:b0:153:b199:10a with SMTP id z20-20020a056870515400b00153b199010amr1099362oak.160.1674134628587; Thu, 19 Jan 2023 05:23:48 -0800 (PST) MIME-Version: 1.0 References: <20230112.120338.534662300633460797.horikyota.ntt@gmail.com> In-Reply-To: From: vignesh C Date: Thu, 19 Jan 2023 18:53:37 +0530 Message-ID: Subject: Re: Time delayed LR (WAS Re: logical replication restrictions) To: Amit Kapila Cc: "Takamichi Osumi (Fujitsu)" , Peter Smith , Kyotaro Horiguchi , "Hayato Kuroda (Fujitsu)" , "shveta.malik@gmail.com" , "dilipbalaut@gmail.com" , "euler@eulerto.com" , "m.melihmutlu@gmail.com" , "andres@anarazel.de" , "marcos@f10.com.br" , "pgsql-hackers@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 Thu, 19 Jan 2023 at 18:29, Amit Kapila wrote: > > On Thu, Jan 19, 2023 at 4:25 PM vignesh C wrote: > > > > On Thu, 19 Jan 2023 at 12:06, Takamichi Osumi (Fujitsu) > > wrote: > > > > > > Updated the comment and the function call. > > > > > > Kindly have a look at the updated patch v17. > > > > Thanks for the updated patch, few comments: > > 1) min_apply_delay was accepting values like '600 m s h', I was not > > sure if we should allow this: > > alter subscription sub1 set (min_apply_delay = ' 600 m s h'); > > > > I think here we should have specs similar to recovery_min_apply_delay. > > > > > 2) How about adding current_txn_wait_time in > > pg_stat_subscription_stats, we can update the current_txn_wait_time > > periodically, this will help the user to check approximately how much > > time is left(min_apply_delay - stat value) before this transaction > > will be applied in the subscription. If you agree this can be 0002 > > patch. > > > > Do we have any similar stats for recovery_min_apply_delay? If not, I > suggest let's postpone this to see if users really need such a > parameter. I did not find any statistics for recovery_min_apply_delay, ok it can be delayed to a later time. Regards, Vignesh