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 1wT9lV-000LtS-1g for pgsql-hackers@arkaria.postgresql.org; Sat, 30 May 2026 02:49:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wT9lU-005CGf-0F for pgsql-hackers@arkaria.postgresql.org; Sat, 30 May 2026 02:49:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wT9lT-005CGW-2T for pgsql-hackers@lists.postgresql.org; Sat, 30 May 2026 02:49:32 +0000 Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wT9lS-00000000FGe-0jTa for pgsql-hackers@lists.postgresql.org; Sat, 30 May 2026 02:49:31 +0000 Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-3966c0d5ac9so866061fa.2 for ; Fri, 29 May 2026 19:49:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780109369; cv=none; d=google.com; s=arc-20240605; b=jCHnUJe1xMdZeab5oMbBoiJqa2ZEJoVp+RMZfml2gT6DMKIJ+MsxfFEJumu8RZ2KWz 40iuT2l5E5/Pn1AcA+7D5lbEMQP1vjbtOdYFqLC72FVEqcosWqfYCXCTSlos8ooFtx2h 2ByRhf+le0tHhgR2TstL3crv6iSomGlTY1sVysyN0FdzvfSAhZ/JEFAyTFl34pzrxzas pxqF3T29TJnFvebgfjuWaRGWBc2gqQJe7F/WOBpMFrbQW1C5/U4hTGMSLvXYvKIwe2F9 BIZDxSqk72O/qsfzbSbQQf/SIddPjR8wdgCFiev1PG6q3XTt0oYWvozTB0zkMUwezTUv 65Lw== 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=05rFxnzYHyg58hU4zIn1A5sXT8fjDo3OwAG/rkInYXo=; fh=W1indjgpHHNtnTsQxnNyt04JRsjcD8foijGhY7tu9ag=; b=dVexE7mXxO5YmmBfjZsl7O3vONb6iBok+AeCNPd8d//ZyycIlciQhXve5Y+dirGiz/ acfJLUMVo9/AE06DFf75QlzQ7Q/Fpx6dF780JpFQXfmuYkwgk0c3z1LN1HZ64L6MpK7v KaCUh6m8IEswykaqv8DVMrDVv0vY1+gvfcOKWavkLf5foyMR+lWXYafp0FrT0bCeWfo8 p/aWmJpXni3+Ek53SOPdp7P529AS6o35mrVf4iFG9rPiC4GQ6d8whHcPqbmtiox7CVJW jnBfjHGtqAvQxfDUm9/xjc13cx1EaIs5Lbc9fZzUmiZguwrDKr6mUS1Aql4cNLrPCefJ wD8Q==; 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=1780109369; x=1780714169; 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=05rFxnzYHyg58hU4zIn1A5sXT8fjDo3OwAG/rkInYXo=; b=g7aJf44OZtFILRaM6pq06r8uRw8b+bgVhwYwvv68GIgS6VSIMcTYMm060Z2COmM85i c7trZRZsmaB/aUPU7s0dvNj56gLQHptlIGVG4C5qlCq4ftAg5whTWckyJQgu07eKe9Ru JzSESqQNpa6cdAc2EjaQO3jZNR9NR8ifrTzF1fp1nz5dcgM+2RhC7BRKL8Vv0i1xijoW jOlGeXAXmhzTZpCcZup/pAWGxDpU7WQlAgxZruw8gfV11wROP4g0GiZYwFWYHoMWB9mJ llxFhpyYm4yfrYd9lfheveqpcUJVpfAoHOHEu5j9Kw0HLm/qiyTkquHRi0/wV6fOPsF9 +5jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780109369; x=1780714169; 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=05rFxnzYHyg58hU4zIn1A5sXT8fjDo3OwAG/rkInYXo=; b=FQSvBL2YRlN0mwjWHiyA4/7kQ6gcpVKKGvIFwpH11eoKFkFW2kxfeAtTeH98BlWRJh r5c6/NkwzIlE/LBK07UaIjvspoyBm3JNjn91bBuDmJW8V1NOPYXTu6y8tJ5iOwxlCEsi cr+uBE8giedBDLkKm/9B0Tt7CYulHjbELXwByslHXMBUnEQeKFvpAMkC3wGAHot/Vl+O iUO4PRdNBzt8whqto89tIZjw3PO/sR6cXukCmTGp9azNfLC190bG/3RcKVZbHqzYg01k 8/74uslnxlNtRFpE7KDZeh3Hyo+Cv+cgDt+IFVoBI+I6lhdBl0pwn7CbIjp+1LIpw5fh Vo5A== X-Forwarded-Encrypted: i=1; AFNElJ+KfBbkUfElBaTWXPzPfPILwEXxY+z+8AcCEXI3Il0f0LiqglVSxZk0QyiDVIS72oVQ7CLPscTJuAiW2tx0@lists.postgresql.org X-Gm-Message-State: AOJu0Yw787/t16A2wWvu5zJqD9TMXJscgWGUrnsZsFujPfV6+AHbuwGK 0DriCWQ+lLcTcQi8Pf32J/ebSPb7EAxiYiVeESebGuw5I5l9M6Tvtsx/2HKt8bziF6ac1XeZf0g bLm2tHZZmJpGKxHGao2bG2XUWLTxfyQ== X-Gm-Gg: Acq92OGL8NOe1Y8vy5Nmq5PdFL6Ib6Xpi2JtMghIHIr9JNGnCieZGDAbjB6b/cv0U05 Uc6lfe62WXb8K91i3/gUELL8QTZ9FPamdA4VOEDfpMZ465p+Yl04hh+PrkKyW6usW15/+JTgx6j ucj++AHa2aag53NBOWlFalEbLR74FGXyNNNGwjoTm87hmkl7Rp+7FHdQGNWfa8IFprKDsYh5sYY YG+LfFhrRGQPHh9qfKZM0KrZrmZNdM7UkqqobCxOUg2GW2sn30fUqvNZ9q4+5cFdPY8jZk7NWpw Ojj2cOmR+gQGySdOuwU/tdSeVHSSFEnVSfhMQ9hYzhLWTLJLlQ== X-Received: by 2002:a05:651c:4199:b0:394:3deb:f360 with SMTP id 38308e7fff4ca-39664f2df85mr4131441fa.20.1780109368230; Fri, 29 May 2026 19:49:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nisha Moond Date: Sat, 30 May 2026 08:19:15 +0530 X-Gm-Features: AVHnY4Kk1XXBLw9k0gtdOd9HE3I2yQ_NV7t99y7BGHbUR2iGtMoPzBJMJm_584E Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: Amit Kapila , vignesh C , Peter Smith , 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 Sat, May 30, 2026 at 3:24=E2=80=AFAM Dilip Kumar = wrote: > > On Fri, May 29, 2026 at 5:11=E2=80=AFAM Amit Kapila wrote: > > > > 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 wrote: > > > > > > > > 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? > > But in this case we are talking about the JSON column of the CLT which > might contain a full local tuple or even multiple local tuples if a > remote tuple conflicts with multiple local rows. So, IMHO, we need a > toast table. Nisha, have you already tested the scenario? If yes, can > you share your test case? > Hi Dilip, Amit, Yes, I tested the scenario. Used below steps to reproduce the error: #Publisher: CREATE TABLE fat2 (id int PRIMARY KEY, col1 text, col2 text); INSERT INTO fat2 VALUES ( 1, (SELECT string_agg(md5(i::text), '') FROM generate_series(1, 200) i), (SELECT string_agg(md5(i::text), '') FROM generate_series(201, 400) i= ) ); ALTER TABLE fat2 REPLICA IDENTITY FULL; CREATE PUBLICATION p3 FOR TABLE fat2; #Subscriber -- create subscription s3 for publication p3 with conflict log table (after table syncs): -- modifying the row locally UPDATE fat2 SET col1 =3D (SELECT string_agg(md5(i::text), '') FROM generate_series(601, 800) i) WHERE id =3D 1; #Publisher (triggers the conflict): UPDATE fat2 SET col1 =3D (SELECT string_agg(md5(i::text), '') FROM generate_series(801, 1000) i) WHERE id =3D 1; Above should cause the reported failure. -- Thanks, Nisha