On Tue, Oct 27, 2026 at 8:57 AM shveta malik <[email protected]> wrote:
>
> On Mon, Oct 26, 2026 at 5:31 PM Dilip Kumar <[email protected]> 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.
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.
--
With Regards,
Amit Kapila.
