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 1mZZRX-0002qb-VQ for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Oct 2021 14:04:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mZZRU-0008Vq-Jp for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Oct 2021 14:04:44 +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 1mZZRT-0008Vh-O1 for pgsql-hackers@lists.postgresql.org; Sun, 10 Oct 2021 14:04:44 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZZRM-0000AJ-3E for pgsql-hackers@postgresql.org; Sun, 10 Oct 2021 14:04:42 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3A2615C0124; Sun, 10 Oct 2021 10:04:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sun, 10 Oct 2021 10:04:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=6CgyyZVqifw/ZAI7RrS6YOrle0L1d8k+SL402wG4e bQ=; b=nDZY33m9aqv4jRzLUXM8VLNJ5mbcvyBzUcH+cNnVEDp21Wvat9JwW0SD/ 7dvp32Q4TRWN/Ex7x1krLv6XwqfcqcEKlSWMcxJfCkhLIgrNMkbkmarL8yUOI6OP Uu2/tAdqm24xId7zc/e/Su8BSn5+V6vngxgt0BDCktDNMQ7i92BInSl/EprWVcyP 9DiadN5gqBedoOuWO/ZxFd1VE5E292eV6LmPeTeYb4iXE6etsv3nI/DlnR1cCikV URfl4DQcYPPi6aVuBn7JW/FilMV3sDHgPPIp0a3vHAQ1Tng8rv9TJ8tVSiuNNYXF m3pXPZmNpErpLL7k4lvtlYyS6+DAw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtgedgjeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepkeehieehvdegueeghfff ueeliedvgfeigffhheevvdegfefgfeetgeejudejjeehnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhht segvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 10 Oct 2021 10:04:32 -0400 (EDT) Subject: Re: Skipping logical replication transactions on subscriber side To: Masahiko Sawada , Amit Kapila Cc: "houzj.fnst@fujitsu.com" , "tanghy.fnst@fujitsu.com" , "osumi.takamichi@fujitsu.com" , Alexey Lesovsky , PostgreSQL-development , Greg Nancarrow References: <3163a085-66e6-426c-f97b-8df66980c7c4@enterprisedb.com> From: Peter Eisentraut Message-ID: <2a9287f4-a870-ee93-d032-b93d7e908ba7@enterprisedb.com> Date: Sun, 10 Oct 2021 16:04:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 04.10.21 02:31, Masahiko Sawada wrote: > I guess disabling subscriptions on error/conflict and skipping the > particular transactions are somewhat different types of functions. > Disabling subscriptions on error/conflict seems likes a setting > parameter of subscriptions. The users might want to specify this > option at creation time. Whereas, skipping the particular transaction > is a repair function that the user might want to use on the spot in > case of a failure. I’m concerned a bit that combining these functions > to one syntax could confuse the users. Also, would the skip option be dumped and restored using pg_dump? Maybe there is an argument for yes, but if not, then we probably need a different path of handling it separate from the more permanent options.