Re: Improve conflict detection when replication origins are reused

On Fri, May 15, 2026 at 3:27 PM shveta malik <shveta(dot)malik(at)gmail(dot)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.

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.

Thoughts?

--
Thanks,
Nisha