Hi,
On Thursday, September 3, 2026 6:39 PM vignesh C <[email protected]> wrote:
> On Wed, 2 Sept 2026 at 06:05, Masahiko Sawada
> <[email protected]> wrote:
> >
> > On Tue, Sep 1, 2026 at 4:55 AM Amit Kapila <[email protected]>
> wrote:
> > >
> > > Agreed that the allocation of more than 1GB for a single row is our
> > > limitation besides the bug-fix patch we are discussing as can be
> > > seen by both INSERT/UPDATE cases. Though UPDATE case is slightly
> > > different as there we are generating such a large tuple (by fetching
> > > the entire toast tuple data to WAL log as old_tuple) for the REPLICA
> > > IDENTIFY FULL case, so one could expect it to work. So, if we want
> > > to leave this limitation for UPDATE/INSERT as it is and just
> > > document it (if not documented already) then it is okay to proceed
> > > with the current approach to fix the issue reported by adding
> > > another case to the limitation.
> >
> > +1
> >
>
> Added a documentation to mention about this limitation, the attached
> v6 version patch has the changes for the same.
Thanks for updating the patch.
I think we could improve the documentation a bit.
First, I think we should mention the exact cases that could lead to this
failure. Also, instead of pasting the error message here (normally we only
paste error codes inside <literal></literal>, and this internal error doesn't
have one), we could simply mention that a failure can occur. And since "1 GB"
is not an accurate number, we should indicate that as well.
So, I came up with something like the following:
When the old row is logged with values stored out-of-line inlined,
which happens for all columns with
<literal>REPLICA IDENTITY FULL</literal>, and for unchanged out-of-line
columns preserved because a row-filtered publication's update changes
the replica identity key, the <command>UPDATE</command> or
<command>DELETE</command> fails if the resulting row image exceeds
approximately 1 GB, because it must be formed in memory as a single
tuple.
Best Regards,
Zhijie Hou
