Re: Proposal: Conflict log history table for Logical Replication

On Thu, Oct 22, 2026 at 5:23 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
>
> On Fri, Oct 16, 2026 at 8:03 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> >
> > Attached is v82, which addresses the comments on v81:
> >
>
> We have not yet documented that, in rare cases, the subscriber can
> still fail with the 1GB error when recording a conflict.
>
> The 64kB cap on replica identity values is checked after the key
> value's output function has produced its text, so it limits what we
> store, not what we render. Normally that's fine: the publisher already
> rendered the same value to send it, which keeps the text well within
> the limit. That doesn't hold in a few rare cases:
> - the key column has a different data type on the subscriber (e.g.
> text published into a numeric[] column);
> - binary = true, where the publisher never produced the text;
> - the apply worker's bytea_output or quote_all_identifiers differs
> from the publisher's.
>
> In these cases a small stored value can render to more than 1GB, and
> the apply worker errors out.
>
> The attached top-up patch 0004 documents this limitation and adds an
> XXX comment in build_index_key_json() describing these cases.
> Patches 0001-0003 are unchanged.

I agree with these scenarios and the need for documentation. But I
have polished the doc change in patch 0004 a bit and attached the
updated patch as text. Please take it if you agree. If we prefer not
to elaborate on the details, we can drop the scenarios while retaining
the rest of the wording.

thanks
Shveta