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 1nD52j-00076C-CU for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jan 2022 13:42:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nD52i-0004cz-6q for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jan 2022 13:42:28 +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 1nD52h-0004cq-Te for pgsql-hackers@lists.postgresql.org; Thu, 27 Jan 2022 13:42:27 +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 1nD52e-0004BY-OL for pgsql-hackers@postgresql.org; Thu, 27 Jan 2022 13:42:26 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A101A5C0132; Thu, 27 Jan 2022 08:42:22 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 27 Jan 2022 08:42:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=u9OjMwF9hDxsz3kMne/HFHJUz85vs4GjR7n5myljp co=; b=NoVXq/OaRTnSn0gC3ol9dhAD1xMLjMNzo9bChgDZfRz3k7rywFJneefcB LCGMj/xFqtdyHRgTJYFsHDqsg+0UcwDyLLwrGqtrGFsbEY8PUcDUP8vnoVx8Vu6a Rp7lR+GDF6XQwhidVtdcZYlJOFmnppHGj7voo6Ud1XUFKza2Y51Vu7va7LIx31be YPjVvV/mKULJ/Gkd7iQPXDkwpl2J04V7hc76oqkUdNTjA/zr93tb+50dB2sRCYY3 kNUYmQmPFxSqzAtL+QkiW3/xnOLyb9P1pN+c22gS58nyxZnYC4S+F8H85MniliM9 HeDv7GG7LK/XTmcRtQTRtXpIFXJEQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeefgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvghtvghr ucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvghnthgvrh hprhhishgvuggsrdgtohhmqeenucggtffrrghtthgvrhhnpeefjeegheetuefhveevudel ueeftdejteeiffetvdduhfdtieefgfeutedtveeggfenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghuthes vghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Jan 2022 08:42:20 -0500 (EST) Message-ID: Date: Thu, 27 Jan 2022 14:42:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Skipping logical replication transactions on subscriber side Content-Language: en-US To: Masahiko Sawada , Amit Kapila Cc: "David G. Johnston" , "tanghy.fnst@fujitsu.com" , vignesh C , Greg Nancarrow , "houzj.fnst@fujitsu.com" , "osumi.takamichi@fujitsu.com" , Alexey Lesovsky , PostgreSQL-development References: <9c28c90c-f5b5-d8b9-e9b3-6af21b976725@enterprisedb.com> <78a7ef21-bb27-f78a-521e-94ddb4d5c669@enterprisedb.com> From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 26.01.22 05:05, Masahiko Sawada wrote: >> I think it is okay to clear after the first successful application of >> any transaction. What I was not sure was about the idea of giving >> WARNING/ERROR if the first xact to be applied is not the same as >> skip_xid. > Do you prefer not to do anything in this case? I think a warning would be sensible. If the user specifies to skip a certain transaction and then that doesn't happen, we should at least say something.