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 1wQHrI-001PV3-14 for pgsql-hackers@arkaria.postgresql.org; Fri, 22 May 2026 04:51:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wQHrG-00CKjI-07 for pgsql-hackers@arkaria.postgresql.org; Fri, 22 May 2026 04:51:38 +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 1wQHrF-00CKj9-2M for pgsql-hackers@lists.postgresql.org; Fri, 22 May 2026 04:51:38 +0000 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wQHrE-00000000qAm-2Uy4 for pgsql-hackers@lists.postgresql.org; Fri, 22 May 2026 04:51:38 +0000 Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-39393ec4ed0so63243211fa.0 for ; Thu, 21 May 2026 21:51:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779425494; cv=none; d=google.com; s=arc-20240605; b=IwCXqwTBBDLYEJypC+FhxQhDbat6ueDQWNB2tzYsDQHp6h1U0yFYcenzX4D0CooIT2 7yZE4yNawgEgufQTC7WEhynOd86FMdzs8Vjn8DrEiP+GL7bSvxEGgEDnLkK2Tu8imCTf zOaht4NGxjbzJAexdiHIkOIldhvYS6/WrsrEnLluCpuooVVJq39EBqRDIWlrzua/BvjD EAHd/8eCXpXOt0MjEYpm0wg4tVrHgPz651biUGskbB5LAoJfeFkNiZMPHXkT5+EyoW64 7Jj3kTutYFMtoHa8fg8IvppbptIKZ+sZDDejMiB1nqt0cm/GbUTbgKI1eL9SFJP8J2nN pOCw== 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=ZjsNNikbxLMJfpeoMriD56hJrvduBHVNFb5ZabTyXx4=; fh=MjCHuHavpikfAmb5kiwnqm1OKvPpBjDEVQm3FTb+dt4=; b=Ed34kJ27XfvHmJ8dLmVtRTMUpiLHR+w/4B+L87z9HyoSTQHyj46xeadlyZOCu2WDzn k3D0dHeVHB+1JIipvV2ZczbdE5/TIBa60DHWhjiCDogdlUKq5eoGHdflcyWHi8oIxXmd JMBtZ/mwySRwf+Keg7T4TVSD3AK4NEh9OjOPGucbkWiuUckbCAUG37+UzEUM9484oTrJ QICSebI7bBYtJJRPU7gQCuDGuQEuOxDQCbfIA6oRl8g/uCo5heVJO4xM/RLxyMBlhMZ/ 9DMAS0wHfwsoZm56GZ28EfwUyzqrT4r2dW1poQ7jmxWfWMeufz2N6Gp0hvLpLrcEZaS9 VgSA==; 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=1779425494; x=1780030294; 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=ZjsNNikbxLMJfpeoMriD56hJrvduBHVNFb5ZabTyXx4=; b=JSlc3Wen1EPW+jCLl+aqwsmWnfxZ1DZQ+WIYdg8Ogi0GDv4qqbF5Ivp/k5aGeaKcEh x/LI6l44QxN69WXad/OHl9B17g46UNx4M4FtrUEQ01cZ8vOYlLu7QKWpbQfnr71prO3x vvwz9g88Ugw78AX/VYf53bG5wtEWraCQkQIpQys+WhsThuOsluw3AYJzYp2SP7ppm1J1 z/siBoVk/nlQeELFBoA/5duQXRYHXTmxuPwW22u24B5F/TbRReEfeUHFcI8UYWNMbOmq VonO/+FNo+h+0tVQx5nBM/hYHJAp3KIKhFl8JT+9vXIIKnVQv0NQ7gjNQ+j2FDmKSPER YTqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779425494; x=1780030294; 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=ZjsNNikbxLMJfpeoMriD56hJrvduBHVNFb5ZabTyXx4=; b=CDN51bR+qSChmxBXFO/1ZnLA6mqiqE8GTv21e+H+WoTXXd43iCGpq2PrsoN6mw/Tbf e1r80/B1kixqdBWFNj1zPgqg9doGNtztNDTvZAQpVnZEBFRgYqhBIFKdatHz/y9iYSTM z06sOFHdfjckgqcqIZWzph+XT0yDDI28L1sny6qWt19T6FsUC82nKaqIeQVbdk+IAZoK yo5sUNHylTvycoqxRYzeyzmfUaAjhok0OXWqI4exWZmh0M3Gv8iMIhgsM/aMc1XhVecS StrkOv92pAntFEHPNGuT+oh+MrZGOvKt6JySIcczSunmaM6guV35rX6xfi/UOu9UtGCk m54g== X-Forwarded-Encrypted: i=1; AFNElJ9kequXUSjlWQZAWDHDpZfeTBmAsBnDk1lomctSMaM898V4SQrYZjUYRKvJdWdrlfKwj2ioQtB18nOkHxVB@lists.postgresql.org X-Gm-Message-State: AOJu0YzRP2djip3ntGjLeFFNF0E0X+m60SsihjRUwAxL5vyrJLSFbGm4 z8dBnxsjZbHMcKFKOb20EP1rHm8WTKGPlgKZHLsYi1XBotpPQAQSBh3XXV4zVb6cOjXjA1O/1kt /RRUwdiLxw/ZoahzAbDrC6cMAAGkKSQ== X-Gm-Gg: Acq92OEnoUMqbPk4jvnDdIBuPh/5bI1221EZ5gMlv58RAXKGerxPmJ4O3yAgA/1dQtF MOFW1QzxLnYv4uxyk3hfExUPUpmnQdhueZJwjiNnrQv4/NH5UAAA7ZcRUiEj/L89grGfL1YK4Jd px+/babk9NW+CI7WjO4DrVMPVvvkCxfsHknatC0awjVc3TdXTVe8eEP5rxtaMyOUChL7e8bE0/h oaOxeOkCjaQ4BtGwGnxbKBfWbdMOsXRSgCHTYsNq7CFZAcFHrPyGh15aj3SzEK1S5tHdJNAHrz4 XBxou9diUnBd5cxdnfzEOsB0 X-Received: by 2002:a05:651c:1ca:b0:38e:cab9:3637 with SMTP id 38308e7fff4ca-395d89a41f3mr5635861fa.18.1779425493713; Thu, 21 May 2026 21:51:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nisha Moond Date: Fri, 22 May 2026 10:21:21 +0530 X-Gm-Features: AVHnY4L3ZPdGJdAgrJBLQaSVJ5QYue4K-xMQSW8clNS9ejxByuYO8mmn_KMx0QE Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: Peter Smith , Dilip Kumar , Amit Kapila , 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 Wed, May 20, 2026 at 3:05=E2=80=AFPM vignesh C wro= te: > > 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 Noticed that even disable_on_error=3Dtrue does not disable the subscription in this case. We can think about optimizations such as deciding when TOAST tables should be created, or avoiding the error by trimming/capping the data size before inserting into the CLT if don't want TOAST. ~~~ 2) Currently, parallel apply workers do not seem to insert conflicts into the CLT. The parallel worker logs the conflict to the logfile and then exits with an error without handling CLT insertion. A small test to reproduce this with a 't1' table subscription using a CLT t= able: -- on publisher ALTER SYSTEM SET logical_decoding_work_mem =3D '64kB'; SELECT pg_reload_conf(); -- Create a conflict scenario on subscriber: pre-insert a row that will con= flict INSERT INTO t1 VALUES (99999, 11); -- on publisher: big transaction that hits the conflict BEGIN; INSERT INTO t1 SELECT i, i FROM generate_series(1, 10000) i; INSERT INTO t1 VALUES (99999, 99); -- this conflicts COMMIT; logfile: ERROR: conflict detected on relation "public.t1": conflict=3Dinsert_exists DETAIL: Could not apply remote change: remote row (99999, 99). Key already exists in unique index "t1_pkey", modified locally in transaction 842 at 2026-05-21 21:10:51.497681+05:30: key (a)=3D(99999), local row (99999, 42). ... ERROR: logical replication parallel apply worker exited due to error CONTEXT: processing remote data for replication origin "pg_16398" during message type "INSERT" for replication target relation "public.t1" in transaction 720 logical replication parallel apply worker processing remote data for replication origin "pg_16398" during message type "STREAM COMMIT" in transaction 720, finished at 0/01AC9758 LOG: subscription "sub1" has been disabled because of an error ERROR: lost connection to the logical replication parallel apply worker LOG: background worker "logical replication parallel worker" (PID 66271) exited with exit code 1 ~~~ 3) I think somewhere in patch-0005, the remote_tuple and replica_identity columns may have been swapped. The replica identity key seems to be written into the remote_tuple column, while the remote slot row is written into replica_identity, for example: postgres=3D# select relname, conflict_type, remote_xid, remote_tuple, replica_identity from pg_conflict_log_for_subid_16398; relname | conflict_type | remote_xid | remote_tuple | replica_identity ---------+-----------------------+------------+--------------+-------------= ----- t1 | insert_exists | 699 | | {"a":3,"b":11} t1 | update_origin_differs | 700 | {"a":3} | {"a":3,"b":111} (2 rows) -- Thanks, Nisha