RE: BUG #19360: Bug Report: Logical Replication initial sync fails with "conflict=update_origin_differs" PG12 toPG18

From: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, "mostafaa(dot)hasanzadeh(at)gmail(dot)com" <mostafaa(dot)hasanzadeh(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: RE: BUG #19360: Bug Report: Logical Replication initial sync fails with "conflict=update_origin_differs" PG12 toPG18
Date: 2026-04-03 07:24:28
Message-ID: TYRPR01MB1419594753654605E54773C16945EA@TYRPR01MB14195.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Saturday, January 10, 2026 8:57 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Thu, Jan 8, 2026 at 8:46 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
> > On Fri, Jan 9, 2026 at 4:17 AM Masahiko Sawada
> <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > Can we somehow
> > > share the apply worker's origin with tablesync workers so that they
> > > can refer to the same origin ID? Or can we invent special origin IDs
> > > (e.g., > 0x00FF) that are the same as the normal origin ID except
> > > for being ignored by the conflict detection system?
> >
> > How will this distinguish between the initial sync is done from the
> > publisher node we are getting the update vs the initial sync is done
> > from some other node? Can we always ignore conflict checking for
> > initial synced data or do we just want to ignore if the initial sync
> > is done from the same node?
>
> I imagined the former idea; always ignore conflict checking, so we don't need
> to distinguish them. IOW we treat the changes via the initial tablesync as if
> the changes made by the normal backend process (who doesn't use
> replication origin) while using the replication tracking ability of the replication
> origin.

I think for changes made by backend process without setting up the origin, the
apply worker still treat that as a conflict change when applying the remote
changes as that's necessary to local vs. remote updates.

I personally prefer to let the tablesync worker share the apply worker's origin
ID while keeping a separate origin for progress tracking. Currently, the worker
first calls replorigin_session_setup() and then stores the origin ID in
replorigin_xact_state. The natural implementation is for the tablesync worker to
still set up its own origin for tracking, but assign the apply worker's origin
ID to the global state. This gives us per‑tablesync progress tracking while
ensuring that changes from both workers appear to come from the same origin.

A small patch demonstrating this approach is attached.

Best Regards,
Hou zj

Attachment Content-Type Size
v1-0001-write-tablesync-changes-with-the-subscription-ori.patch application/octet-stream 4.7 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Andrei Lepikhov 2026-04-03 07:17:08 pg_plan_advice fails when NestLoop outer side is Sort over FunctionScan