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

On Thu, Jun 4, 2026 at 6:04 PM Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com>
wrote:

> The remaining idea: storing the origin ID in pg_subscription_rel and
> teaching
> the apply worker to skip reporting origin_differs if the origin of the
> update
> matches the one stored in pg_subscription_rel, seems worth considering, if
> we
> cannot find an easier solution. There was a concern about performance, but
> since
> we could cache those tablesync origins in a local hash table and consult it
> during conflict detection, the performance impact might not be significant.
>
> That said, I may have missed some points. I will continue to think about
> this
> and try to update the patch later.
>
> Best Regards,
> Hou zj
>

I have implemented this solution in the attached patch. The patch adds a
new field to pg_subscription_rel, srtablesyncoriginid, which stores the
tablesync worker's origin ID for each relation. These origin IDs are loaded
into a per-subscription hash table after the tablesync COPY completes, and
also when the apply worker starts, thereby avoiding repeated catalog
lookups. During conflict detection, the apply worker checks this hash table
to determine whether the conflict origin ID matches one of the saved
tablesync origin IDs for the subscription. If a match is found, the
conflict is treated as originating from the initial table synchronization
and logging is suppressed. I have not included documentation updates in
this patch. If this approach is considered acceptable, I can prepare the
corresponding documentation changes as well.

regards,
Ajin Cherian
Fujitsu Australia