MIME-Version: 1.0
References: 
 <CABdArM5k7wCxq+L2r9-mLOoPXe_iHgdeRMXc31oxvzSj=xPjFQ@mail.gmail.com>
 <CAJpy0uAW=7WhkmeZYxB9zoGsk1G5itdJQC6srvpqz9hhKF9xoA@mail.gmail.com>
 <CAJpy0uAYRCbVN_QGYrF_u++wdC4oej_w1S3A_BuWtB3Gct7mhw@mail.gmail.com>
 <CABdArM5EspjR2mdjma509hVJ9Czt2jQnMoVZtdMZakP-i=ag+w@mail.gmail.com>
In-Reply-To: 
 <CABdArM5EspjR2mdjma509hVJ9Czt2jQnMoVZtdMZakP-i=ag+w@mail.gmail.com>
From: shveta malik <shveta.malik@gmail.com>
Date: Tue, 19 May 2026 08:49:36 +0530
Message-ID: 
 <CAJpy0uBJwZHDMX9WuXLUC0BrBQm+iWoppQvLB6ZrgC5z=GjPtw@mail.gmail.com>
Subject: Re: Improve conflict detection when replication origins are reused
To: Nisha Moond <nisha.moond412@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJpy0uBJwZHDMX9WuXLUC0BrBQm%2BiWoppQvLB6ZrgC5z%3DGjPtw%40mail.gmail.com>
Precedence: bulk

On Fri, May 15, 2026 at 4:45=E2=80=AFPM Nisha Moond <nisha.moond412@gmail.c=
om> wrote:
>
> On Fri, May 15, 2026 at 3:27=E2=80=AFPM 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=3D11 where i=3D10;
> >
> > 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