Thread

Re: BUG #19360: Bug Report: Logical Replication initial sync fails with "conflict=update_origin_differs" PG12 toPG18

Rahila Syed <rahilasyed90@gmail.com> — 2025-12-23T07:49:41Z

Hi,



>
>         WITH (copy_data = true, origin = 'none', binary = false);
>
>
There is the following note in the documentation about the setting of
copy_data = true
and origin = 'none'.
```
When using a subscription parameter combination of copy_data = true and
origin = NONE,
the initial sync table data is copied directly from the publisher, meaning
that knowledge of the
true origin of that data is not possible. If the publisher also has
subscriptions then the copied
 table data might have originated from further upstream. This scenario is
detected and a
WARNING is logged to the user, but the warning is only an indication of a
potential problem;
it is the user's responsibility to make the necessary checks to ensure the
copied data origins
are really as wanted or not.
```
Kindly check if this is happening in your case.


    Observation:
>
>         The COPY phase starts and writes data to the disk.
>
>         As soon as COPY finishes and the worker switches to streaming to
> catch up, it crashes with the following error.
>
> Error Log:
>
> LOG:  conflict detected on relation "public.player":
> conflict=update_origin_differs
> DETAIL:  Updating the row that was modified by a non-existent origin in
> transaction [TXID] at [TIMESTAMP].
> Existing local row (...); remote row (...); replica identity (id)=(...).
> CONTEXT:  processing remote data for replication origin "pg_..." during
> message type "UPDATE" ...
>
>
This does not seem like an error and the apply operation can proceed
successfully even after logging this. Can you please check if there is
another message with ERROR/FATAL/PANIC log level in the logs?

Thank you,
Rahila Syed