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?
