MIME-Version: 1.0
References: <19360-1952ab7afd799f70@postgresql.org> <CALDaNm3Y6Y4Mub6QC8fZKnNy5jZspELQYCoQF_FL2Zwzweu=og@mail.gmail.com>
In-Reply-To: <CALDaNm3Y6Y4Mub6QC8fZKnNy5jZspELQYCoQF_FL2Zwzweu=og@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Tue, 30 Dec 2025 12:25:37 +0530
Message-ID: <CAA4eK1LxGXR7jOAKh0B8N362S-Q3b6GhBxxcV_HxUaicEPq5Cg@mail.gmail.com>
Subject: Re: BUG #19360: Bug Report: Logical Replication initial sync fails
 with "conflict=update_origin_differs" PG12 toPG18
To: vignesh C <vignesh21@gmail.com>
Cc: mostafaa.hasanzadeh@gmail.com, pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAA4eK1LxGXR7jOAKh0B8N362S-Q3b6GhBxxcV_HxUaicEPq5Cg%40mail.gmail.com>
Precedence: bulk

On Mon, Dec 29, 2025 at 4:26=E2=80=AFPM vignesh C <vignesh21@gmail.com> wro=
te:
>
> On Mon, 22 Dec 2025 at 19:00, PG Bug reporting form
> <noreply@postgresql.org> wrote:
> >
>
> This can occur in the following scenario: commit timestamp tracking is
> enabled on the subscriber; the same table exists on both publisher and
> subscriber; a publication is created on the publisher with initial
> data; and a subscription is created on the subscriber with origin =3D
> none. During the initial table synchronization, the row is inserted
> using a tablesync replication origin, which is dropped once
> synchronization completes. If the row is updated on the publisher
> after the initial sync, the apply worker attempts to update a row that
> was inserted using a different replication origin(tablesync origin),
> resulting in an origin mismatch.
>
> The conflict is logged and logical replication continues normally. No
> crash occurs, and the log entry is informational rather than
> indicative of a failure.
>

I agree with this analysis.

> These messages can be safely ignored for now.
>
> We are currently evaluating possible improvements to handle this
> scenario more gracefully and to avoid reporting these conflicts in the
> future.
>

One idea to safely ignore these LOGs is we could modify the state
management in the catalog pg_subscription_rel to store originID. When
a tablesync worker completes, instead of just deleting the origin and
setting the relation state to ready, it could record the origin_id it
used into pg_subscription_rel.  When the apply worker encounters an
origin mismatch, it checks pg_subscription_rel for that specific
table. If the "old" origin ID matches the one recorded during the sync
phase, the worker knows the row is "ours" and suppresses the log. Now,
as the origin ID could be reused, we could additionally store local
timestamp along with originId in pg_subscription_rel. Then, we can
suppress the log if: row_origin_id =3D=3D srsuboriginid AND
row_commit_time <=3D srsubsynctime.

I think addressing this is much more important conflict resolution to
avoid doing any wrong resolution for conflicts.

--=20
With Regards,
Amit Kapila.