On Fri, May 29, 2026 at 5:11 AM Amit Kapila <[email protected]> wrote: > > On Thu, May 21, 2026 at 9:51 PM Nisha Moond <[email protected]> wrote: > > > > On Wed, May 20, 2026 at 3:05 PM vignesh C <[email protected]> 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? -- Regards, Dilip Kumar Google
