On Fri, May 15, 2026 at 4:45 PM Nisha Moond <[email protected]> wrote: > > On Fri, May 15, 2026 at 3:27 PM shveta malik <[email protected]> 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
