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 1wT5AZ-000J59-1g for pgsql-hackers@arkaria.postgresql.org; Fri, 29 May 2026 21:55:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wT5AX-004bze-36 for pgsql-hackers@arkaria.postgresql.org; Fri, 29 May 2026 21:55:06 +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 1wT5AX-004bzV-1n for pgsql-hackers@lists.postgresql.org; Fri, 29 May 2026 21:55:06 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wT5AV-00000000D4a-3xIx for pgsql-hackers@lists.postgresql.org; Fri, 29 May 2026 21:55:05 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5a8dc2606a0so14221759e87.2 for ; Fri, 29 May 2026 14:55:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780091698; cv=none; d=google.com; s=arc-20240605; b=gMCMUwKhsHZdaKQt9Op9tOAITz81wvLuP7l+xe3Lm0kT5Q0nLKU7p4VjC1URxpv6// mfBR071ub0h8YaeOfSYIT0/NOyGWSOU2SLC5Iy+Devb3k5ik2PKhmu+c1saQtObDl7HZ XzyGwNXcUiU37I4qH9r9zvtKbAPjMha3sO/zSf09eON5ZTraIpsQ5rdPDUqyPx9s79ZA sTyDVfScAoNXty5FzQUhUH07maV3q7WPzIwgcH0aonfLyc08QkJhPSrtObUbU9Tst0OH j9bQ65zeOgH8jsWrmHzdZljuP68tNlHqUgTUE4dd9BPnJb61aBXBup9VaoA255w/fzBY +ahw== 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=KpVzU7GLLqQ9uI8RIOu9CXRETFCnSMFB67F7eeNYzX0=; fh=CQKH6v7PRR5GA0QSbs1B/Y3oXAticuYcAdC8jRG22Ck=; b=YGd8tIa+RYAbdvLVk6B2ottvsfeA2TmiIT1dRLQaO8LZU+uMdEMTksQceWayj/TGS6 EYQskAnz9MNxAn8gPTN8+axuIeYktbylmzEgugdGOERpjI0HnfL3Xm/mo+ppfpD0KMJR 1iwcifwPox3zDbZy32SQcXv83uSFPtnnGvcHN2dLtKWGmWs9YMl2lKks9c8aLTS5qAnQ FE+Ao6fOrWV0N9K0Cv6qiLhDl5qn8deY0/9BCQ8eAXEblAR3lyqNBPR7wVYRtufyuzMw 2N2Wy7FIlpnQ3wfcYlNDgu/S+LFLL3llXs1cG2wRHbg38Zb6+6YHoUAbeuzpaXP0ygdj Sq1Q==; 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=1780091698; x=1780696498; 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=KpVzU7GLLqQ9uI8RIOu9CXRETFCnSMFB67F7eeNYzX0=; b=mT/kpYA8xgHRsZm7d99h55XK3q6A3LrNZg0OMfzKuFstI6vLYnnNaQj13i3NgefxGM ETrhyNwSy7eXsfb/FakLGgbvhDCVVw11ywK82eYHTJ3MvTVfNBysodEGCHes772xreUS bmDP1p1Q/pXgt/b4z6uTDToeINgmy+p1Ddsa2H9syK6M085UyprkDHYyYRaxHV+rKrRq 2u3UzaLWpuU9Z1ehO6xxUxFDbKqpG694xHwXzEkRdb+opnhRlBT7AXVg0BqVzYTspnL/ C1UUDAvYncA/X9JjtY3EPc3Nqfw174zEefPvkJB8yzUX+xA6RzBtiAhlCv0vgcB7wQxu SbCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780091698; x=1780696498; 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=KpVzU7GLLqQ9uI8RIOu9CXRETFCnSMFB67F7eeNYzX0=; b=MQlLkq4p10bN44Dw5CkLI0LA+KYR1v7VgbjG8ZwIonHvq9QmAiYYbmjDvKZoeOcMdO YtEKi0LTjLINx2gbs9vsN/k1z1O4Zhzqz5H2l2MJZErKMcoHfiAomYNdy+92neKTsPaF b5Z2gM41wRv/DBwf30io19teA51wAHYNqYCFSiYXteA6j2dTQOs0PQlY9uQBHMiOR8SW iHuhUsMqk+2mN9kd/Xfh/UddouT8kln9mlDR8fmtIOIyTKsWChRv0XX+SDwEwpCP09id KDjVHVjc4srPaiYf4jjsiyAy3PfsNrM7jeRamXUI35esFuAa2DrbSKMIWON6tyi9VYwi 8AxA== X-Forwarded-Encrypted: i=1; AFNElJ9pTMB9TP8a6H127q6ubPQ1wiW960yfYdvxekmWpSxifwZRAdoxf05JTMh6yPAW2CERDOqy99avvwIqja/7@lists.postgresql.org X-Gm-Message-State: AOJu0Yz2ZC2PrdzewI3KK7ROx2LG1p1G26KexvcaiAJbU/5xc15aivfC g2+Cj1oeLuG6ebARLNHWDPSmEngZGopkP4zmHjECJW3txVGOgTAQd0NwboS3O3/RC2RO0tN3/3y 6gRoXi+oRSWIBsGaeHNsDvyb62IrNHrs= X-Gm-Gg: Acq92OHPZXmvnppnQMsQcbIbzvFbRa3NNBJ7fc4GRUeKmn4v+i4kDclqSS8ynYdLact 8gu+yBGS9+jfuHG+y9ebKKfhB4WUDyatNa9v7sHWiJGV07BAT66iLfNWkACRYouuIzVF8LxlZFW vuz+NM1ffDGlCk1noE2hXrmVpdACEEghlm7Lbtr8IgycdUhD8AdZcxmmvz5UCNGZOaZ4xsylk+X ACLhbDzmBLUpqvvbKKWmf2sSq4yFedymCUooIdgPa1IKWpfNW165Gb4IyaFXHGj7Vrh8t8Bf1M/ NgCYt9xZOWnPO8XlPwnNQq9Ox4tROw== X-Received: by 2002:a05:6512:1393:b0:5a8:fbe0:bc71 with SMTP id 2adb3069b0e04-5aa607b49edmr471040e87.15.1780091697967; Fri, 29 May 2026 14:54:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Sat, 30 May 2026 03:24:39 +0530 X-Gm-Features: AVHnY4IwvX9UORhKKCXnhiT8pskqCbQ-TRJunNTkDovXicTDPfg1GSKIlMhdj4U Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Amit Kapila Cc: Nisha Moond , 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 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? --=20 Regards, Dilip Kumar Google