Re: Proposal: Conflict log history table for Logical Replication

On Tue, Oct 27, 2026 at 10:42 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, Oct 27, 2026 at 8:57 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Mon, Oct 26, 2026 at 5:31 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > >
> > > I am wondering is it right to call it remote_origin? As this is
> > > locally generated origin right?
> > >
> >
> > You’re right, the name isn’t apt.
> >
> > I tried to look into remote-origin capturing: we don’t capture that
> > today. apply_handle_origin() is essentially a no-op; it only checks
> > msg ordering and doesn’t even call logicalrep_read_origin(), so the
> > incoming origin name is discarded. And the publisher sends the ORIGIN
> > message only when the change has a non-local (non-null) origin (i.e.
> > it was itself replicated into the publisher from another source), so
> > it wouldn’t be set for the common case anyway. So I’m not sure we
> > should store it. I’d lean toward renaming the current column to
> > something more apt. How about it as apply_origin:"the origin the
> > change was applied under" or subscription_origin?
> >
>
> I agree with your reasoning and prefer apply_origin as a name for this
> column. BTW, we can merge 0003 into 0001 as that looks good now.
>

Done. Renamed remote_origin to apply_origin. Also merged 0003 into 0001.

> Another minor comment on 0002:
> *
> + save_nestlevel = NewGUCNestLevel();
> + (void) set_config_option("datestyle", "ISO",
> + PGC_USERSET, PGC_S_SESSION,
> + GUC_ACTION_SAVE, true, 0, false);
> +
> /*
> * Build the JSON object here rather than handing the values to
> * row_to_json(), and render each of them with its type's output function.
> @@ -1099,6 +1184,7 @@ build_index_key_json(EState *estate, Relation localrel,
>
> appendStringInfoChar(&result, '}');
>
> + AtEOXact_GUC(true, save_nestlevel);
>
> We can remove this change from 0002 as the corresponding impact is
> documented in 0003.
>

Removed this from 002.
~~~

Please find the updated patches v85. I also incorporated Shveta's doc
suggestion[1] into the v85-0004 patch.

[1] https://www.postgresql.org/message-id/CAJpy0uBfBx3fbZ%3DySEsvSgNQ4k3%3D00wGqLUv44Z6_Y4396Y3sw%40mail.gmail.com

--
Thanks,
Nisha