Re: Proposal: Conflict log history table for Logical Replication

Hi,

On Mon, Oct 26, 2026 at 12:59 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Mon, Oct 26, 2026 at 9:52 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Mon, Oct 26, 2026 at 9:08 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > >
> > > On Sat, Oct 24, 2026 at 11:42 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > >
> > > > The current use of the "datestyle" and other GUCs in libpqwalreceiver
> > > > or in other places is to keep the format portable across nodes but
> > > > here the CLT output will be usually human-readable. So, the same
> > > > analogy doesn't follow here. I am not convinced that this required
> > > > mid-way changing the GUCs temporarily. I feel we can document this
> > > > column and if we still get a request from field for portability of
> > > > this field(s) then we can consider using GUCs to make the format
> > > > consistent.
> > > >
> > >
> > > But it causes ambiguous results as shown in [1]. I am not sure how
> > > documentation will help here. As I see it, the stored key must
> > > convert back to the original value, not to some other value,
> > > especially since the patch’s own docs recommend casting it back to the
> > > column type before comparing. And I don’t think libpqwalreceiver does
> > > this for portability: its comment says it forces these GUCs so values
> > > are output “in a form that is unambiguous to the subscriber.” IMO,
> > > that’s the same goal here: avoiding a wrong stored value, not
> > > portability.
> > >
> >
> > That is a cross-node compatibility case and similarly pg_dump's output
> > could be restored on another node. I feel if a user changes the
> > datestyle or similar settings in-between different conflict-insertions
> > the results can change accordingly. We shouldn't take such guarantees.
> > It should be documented somewhere along with the following text [1],
> > we can probably give a small example as well.
> >
> > [1]
> > + <para>
> > + The apply worker's <xref linkend="guc-bytea-output"/> and
> > + <xref linkend="guc-quote-all-identifiers"/> settings change how a value
> > + is written without changing the value itself. If these settings differ
> > + between conflicts, the same key can be recorded in different but
> > + equivalent forms, and comparing the recorded text may miss some of them.
>
> Okay. Let's do this, we can decide further if we have any real
> customer's feedback.

Here is the updated patch set based on the discussion. The GUC-related logic
has been removed and doc is added. I've also improved a few comments about the
oversized column value and the reason for referring to the table's column name
rather than the index's.

Only 0003 is changed.

--
Best Regards,
Zhijie Hou