public inbox for [email protected]  

help / color / mirror / Atom feed

From: shveta malik <[email protected]>
To: Nisha Moond <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Improve conflict detection when replication origins are reused
Date: Tue, 19 May 2026 08:49:36 +0530
Message-ID: <CAJpy0uBJwZHDMX9WuXLUC0BrBQm+iWoppQvLB6ZrgC5z=GjPtw@mail.gmail.com> (raw)
In-Reply-To: <CABdArM5EspjR2mdjma509hVJ9Czt2jQnMoVZtdMZakP-i=ag+w@mail.gmail.com>
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>

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

view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Improve conflict detection when replication origins are reused
  In-Reply-To: <CAJpy0uBJwZHDMX9WuXLUC0BrBQm+iWoppQvLB6ZrgC5z=GjPtw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox