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

On Tue, Dec 23, 2025 at 1:20 PM Rahila Syed <rahilasyed90(at)gmail(dot)com> wrote:
>
>
>>
>>
>> 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.
>

If this would have been the case then the OP should see a message at
the time CREATE SUBSCRIPTION. The WARNING message in the above quoted
section is the WARNING displayed in check_publications_origin_tables()
which should happen at the subscription specific DDL command.

>
>> 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?
>

Yeah, this part is also not clear to me. The messages shown should be
LOG messages and shouldn't lead to crash or error as seems to be the
what the OP seems to be seeing.

The one thing we can check is whether track_commit_timestamp is set on
PG18 Subscriber node? If not, then you can try once after setting the
same.

--
With Regards,
Amit Kapila.