Thread

Re: Improve conflict detection when replication origins are reused

shveta malik <shveta.malik@gmail.com> — 2026-05-19T03:19:36Z

On Fri, May 15, 2026 at 4:45 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
>
> On Fri, May 15, 2026 at 3:27 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > Nisha, I think we will get the same problem in another scenario too:
> >
> > create pub1-server1
> > create pub1-server2
> > create sub1-server3; subscribing to pub1-server1
> >
> > --On both server1 and server2, insert same set of rows:
> > insert into tab1 values (10), (20), (30);
> >
> > Sub1 (server3) will get the rows from server1.
> > Now alter sub1 to connect to server2 (you will have to create slot
> > manually on server2)
> > SELECT pg_create_logical_replication_slot('sub1', 'pgoutput', false,
> > false, false);
> >
> >
> > --Now perform the update on server2:
> > update tab1 set i=11 where i=10;
> >
> > The subscriber on server3 will receive update form server2 and will
> > update the row inserted by server1 origianlly without raising
> > update_origin_differ.
> >
> > Can you please confirm if my understanding of the problem statement is
> > correct and if the scenario above will also result in a similar
> > situation? IIUC, in such a case, the proposed solutions may not work
> > directly and will need to be further evolved. I will think more once
> > you confirm my understanding.
> >
>
> I agree that the above scenario will not raise a conflict, and I think
> that is expected with the current replication model, which tracks
> which subscription stream applied a row, not which publisher server it
> originally came from.
>
> With the existing replication model, we can also see the opposite
> scenario of what you mentioned: if two subscriptions replicate the
> same table from the same publisher, update_origin_differs conflicts
> can still be raised even though both changes come from the same
> source. This again shows that origin identity today is effectively
> tied to the subscription stream, not the publisher server.

Yes, I agree. Thansk for details.

> If we want conflict detection based on publisher identity, that would
> require a different model altogether, closer to systems like
> BDR/pglogical, which track global node identities across the
> replication chain.
>
> So for now, I think the above scenario is outside the scope of the
> current subscription-level origin tracking design.
>

Yes, looks like so.

thanks
Shveta