Re: Proposal: Conflict log history table for Logical Replication

On Fri, May 29, 2026 at 5:11 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, May 21, 2026 at 9:51 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> >
> > On Wed, May 20, 2026 at 3:05 PM vignesh C <vignesh21(at)gmail(dot)com> 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