Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wSkMK-0004CH-2m for pgsql-hackers@arkaria.postgresql.org; Thu, 28 May 2026 23:41:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wSkMJ-000t9r-0S for pgsql-hackers@arkaria.postgresql.org; Thu, 28 May 2026 23:41:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wSkMI-000t9i-2L for pgsql-hackers@lists.postgresql.org; Thu, 28 May 2026 23:41:51 +0000 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wSkMG-000000002Ja-1qDB for pgsql-hackers@lists.postgresql.org; Thu, 28 May 2026 23:41:49 +0000 Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5a88de2b52eso15994788e87.2 for ; Thu, 28 May 2026 16:41:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780011706; cv=none; d=google.com; s=arc-20240605; b=eqvMAKHoynLXX9SIDhHJMORBb66PfRPS4Ryhs2PmAn+UsrHiQovYFKQKCr4kiiojw9 4PQW8Cl1ri8Lz5vZ0OTyThL2B+/jv3+0q/ux/oa4ebdUrF3vx5mxnbUa8+R8fSlEEIwj xHDbUxw37hVMTQN94J+j+Hdb82Vi84jvY0ojPO1T9FkN6lvy+DEqeZC4eCtdn5Rpjf0B 4R5lJGfPtGgFD84Q7Bq2VZ62e7eiN+jN278re8K1qyG9mt5MJEqjGZ0y7CsLqpMJWXLC gODBs4ei8MB/ZUXOa7+pn+Xr0qzbWXC2t85W/uBoAg7pdDLSRT3iAOjYUYayGm6igDmW BiSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=V9N5xYErVEbGMu+kzOAN9lfOxfGjE8MBZWn0M79DdTc=; fh=30KSIN5nSH+BhK0ubANqw9VgWKqDB1zKGcCgC6sPkLY=; b=O3dFqgjHTVEVUebT7kbo3gBEkJ/qkOq+bXkgFyZGab7RkpPQ2LgFcCMthDUwUNIJzf izUQstvYrva82NbK5uIsqmGdxHeeQXZWaMBu6dSWRRfZvceykiyR2SF/1jUMArh9eOPL 6FVcUYdp4tmEXyGeONr4vTj4LN0IZVJJkdEiHrMW7eG0ehKuP4KwEuhxs62ucCwxE6Tf T+vUUTaN3PHNBwJr7d0xNv75BDBBI2u9aasL0qxb3hj77BoHi3hhc4274eU/SkLiQx3w 4pOCz1Ufw4z++hJjfMNd85OXIW54u06xt8q8m8PXx/APPMj7wLr6bHyLQ37/3C9w1pjQ wcpQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780011706; x=1780616506; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V9N5xYErVEbGMu+kzOAN9lfOxfGjE8MBZWn0M79DdTc=; b=Y9099THraT61YJ4lpmcXj+ZxryzAet/hb59GxJKYUd6X59zFNqengOFoNujoHM1yX+ hr7Eu2P+kw9AnS26izfIT6exxWuVpHJBLfpnB91n1dRDh+19JXWSYqT5LFPg9iMbay+1 BiW1wYnC0X0eamzVEz9mfOPPWvBLl+sNJu5h35zT9qUquTExKgkxx7vPrVI6QXRurnUz HCX/pcKFlwDS8ZIs7UPDFCCdnQNJYTDa043XOhIH/juF9luP5qbzYRmnFnxphQ18DBik ugJTxrLUZEI9hWAd4QjwaRvQirqVxwDVZ3uc0SdNXcJF89BqEqlwWXrcy9CfeijydMmG KH4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780011706; x=1780616506; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=V9N5xYErVEbGMu+kzOAN9lfOxfGjE8MBZWn0M79DdTc=; b=GzX4L7RgZWyylWnkteWhOM/DIVL/pYJONB8t/BHuMhADUiKo6AJS5c9UZBY/ctuwIh yMRdzARjCk4zl5qF2lYCeTnTm6b8M+hs2FvsYdPeciuA+ALkeI3UcWkjUiJg9lWuoSPK EHvdwl3maiLwNIla6scjhOOztYKimG+dDJkr6vAR5bNsmPPsoYJbtDuFSFtYDHlrajkI +8te2sPkRUz+IZpr5jbipka8vxhKeSwAX9DwFLVv94v+4q8ar31Np37p/6hFZ6HDqCZB T2bNANbkrM492i0X5wxghjQ6BZ0jHhZ7MtTCbaybuqVG46lh+HhlY9VXfvGUE+Uk5W82 +NNA== X-Forwarded-Encrypted: i=1; AFNElJ9MWHbe7G19oV68XhsmXsUm0IGSTDsGlfNnMrWE/cab11XIyMyTYVDQrp/J/blVwI0fXSxFfphTaUNxzxDX@lists.postgresql.org X-Gm-Message-State: AOJu0YzHTM5QZb3jdkjGufd6wviMFLEzhSArGBUicXEesF0M4klLpFkZ sOfsUDo9qkBh5Lzkm9Ea419+AjxDXyya25gCoUE4psXsGRbjegtGotLGPfsR2d/JHmmEQAvzaii WbrjAoE15gD6+dM4mp3oCz3b3DEcs43w= X-Gm-Gg: Acq92OHKS2CnDyos69sZeuA9pNNieM8+BGHD4+WtMQ/uiTV5YOLRHqTXC1vWDGVatb+ vukLFsjk4jnJRjHPVnOHlxSi9UEG/Mo790+LFiuMeocJ/rnsz2pSQ9MoEkau0Ak6pNBdSNYtzL7 pl3pUnA1oZvfF/QSNYOswNfQI0EI8w50qQKZcB7Ec/z8mrquOJcK+iIe4I/MBb4/t62llX4cPnQ bHGbdR4SY9hIG5y0roCxUKjBwqv/n8vNskp3J8O/VFUbQhtEHHXw18pRmk8rnu1W/tjo7YfmMWt H2nBOaLM5aSN1CZmEHQrU2P+Ksa9cs6ge/+8rouxLhCY0qEyTQEjhBLGlVLDIl6PmhPIi2rN57z z+hvcd0l2cU3+WuBc8g== X-Received: by 2002:a05:6512:3983:b0:5a3:fcb2:c6a1 with SMTP id 2adb3069b0e04-5aa59436af3mr100927e87.13.1780011706134; Thu, 28 May 2026 16:41:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Thu, 28 May 2026 16:41:34 -0700 X-Gm-Features: AVHnY4JuaM97_hSz7e8EjQD1ML2SwJNP07viDpgacHkxAurHZIzeQfb5sIdUq-U Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Nisha Moond Cc: vignesh C , Peter Smith , Dilip Kumar , shveta malik , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers , shveta malik Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, May 21, 2026 at 9:51=E2=80=AFPM Nisha Moond wrote: > > On Wed, May 20, 2026 at 3:05=E2=80=AFPM vignesh C w= rote: > > > > Rest of the comments were fixed. > > The attached v37 version patch has the changes for the same. Also > > Peter's comments on the documentation patch from [1] and Shveta's > > comments from [2] are addressed in the attached patch. > > > > Here are few comments based on v37 testing: > > 1) Should we consider using TOAST tables for tuple-data columns like > remote_tuple and local_conflicts (the JSON columns)? > This may be a corner case, but if the tuple data becomes too large to > fit into an 8KB heap tuple, then the apply worker keeps failing while > inserting into the CLT with errors like: > > ERROR: row is too big: size 19496, maximum size 8160 > LOG: background worker "logical replication apply worker" (PID > 41226) exited with exit code 1 > In the docs, it is mentioned: "column_value is the column value. The large column values are truncated to 64 bytes." [1], so I wonder, if we follow this why we need toast entries? Did you tried any case where you are getting above ERROR? > Noticed that even disable_on_error=3Dtrue does not disable the > subscription in this case. > Hmm, I think we need to have a documented reason if such a case doesn't disable the subscription with the disable_on_error as true? [1]: https://www.postgresql.org/docs/devel/logical-replication-conflicts.ht= ml --=20 With Regards, Amit Kapila.