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 1lnnY5-00068w-Nz for pgsql-hackers@arkaria.postgresql.org; Mon, 31 May 2021 19:26:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lnnY3-0004j4-KM for pgsql-hackers@arkaria.postgresql.org; Mon, 31 May 2021 19:26:03 +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 1lnnY2-0004iv-Rh for pgsql-hackers@lists.postgresql.org; Mon, 31 May 2021 19:26:03 +0000 Received: from wforward4-smtp.messagingengine.com ([64.147.123.34]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lnnXz-0006Ux-LS for pgsql-hackers@postgresql.org; Mon, 31 May 2021 19:26:01 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.west.internal (Postfix) with ESMTP id 949C717EF; Mon, 31 May 2021 15:25:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 31 May 2021 15:25:57 -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=fm2; bh=V/NqjRPGdISgB68f0pz5mC7rItvv2GgqhXSuukVbN cQ=; b=E1/zvZps0tVXkgNMUDz9dv1PQn/tEmYYS8hwcxkNC/85fbi2pEjXd+FI1 l5o0202srTfKQIzk7ZqaE04ksR8maHFeYH9wNbf7gAW1w1t7thlXBSJ9HjAmkrP7 r+fFfBfkZdoWKyEc8vBIpRSewR1a2dpn7Ei3F+7MmSGcdBYWh2+dDbkp01LasHOB /APrxLEQSCoXa4goev0JKktkmlBieyvJfFIE78GP01e171qbKXPgfWPzPwVj/Ek9 47T1HZksQlgQwxSWH/vaqaU8TeTR8mdqLnE39wDAEjJCQPzPE3UKqY+0PuItAk5J EROn+GX0Rd3dAL1QfokEnqW09RR4Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelfedgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvght vghrucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvghnth gvrhhprhhishgvuggsrdgtohhmqeenucggtffrrghtthgvrhhnpeelveehheeuieduieet iedtkeeuteelfeetjeffieffudegvdffvdfftdeivdeukeenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghu thesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 31 May 2021 15:25:56 -0400 (EDT) Subject: Re: Skipping logical replication transactions on subscriber side To: Amit Kapila , Masahiko Sawada Cc: PostgreSQL-development References: From: Peter Eisentraut Message-ID: Date: Mon, 31 May 2021 21:25:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 27.05.21 12:04, Amit Kapila wrote: >>> Also, I am thinking that instead of a stat view, do we need >>> to consider having a system table (pg_replication_conflicts or >>> something like that) for this because what if stats information is >>> lost (say either due to crash or due to udp packet loss), can we rely >>> on stats view for this? >> Yeah, it seems better to use a catalog. >> > Okay. Could you store it shared memory? You don't need it to be crash safe, since the subscription will just run into the same error again after restart. You just don't want it to be lost, like with the statistics collector.