Other: Improve HVR loop detection on postgres
Thomson Reuters has the following issue.
The have have for example 2 uni-directional channels
channel1 oracle to postgres
channel2 postgres (same location as target for previous channel) to postgres
These channels have multiple integrate locations for parallelism
If they add a new integrate location to for example oracle to postgres, a new hvr_sti* table will be created, but capture on channel 2 does not know of the existence of those tables and will re-capture changes until that capture is stopped and restarted.
Same issue they have with refresh
if they refresh channel1 , the capture of channel2 picks up the changes until capture is stopped and restarted.
Now for only 2 channels this is easy to manage, but they have 100's of channels.
Customer wants a better solution to avoid changes are re-captured , causing out of sync/duplicate key violations.
-
Official comment
Hi Rakesh,
Product management asked me to update you with the following information on this feature request.
For loop detection on Postgres, Fivetran is planning to use the replication-origin feature for this as in https://www.postgresql.org/docs/current/replication-origins.html.
Fivetran plans to build this new approach to loop detection into HVR by the end of calendar year 2024.
It is going to rely on native support for pgoutput that we will only have in HVR 6.2+.
The capability will not be backported to HVR 5.x, and until the new loop detection is created we have no plans to enhance the current approach.
Greetings
Herman Verheul
-
Hi,
Any updates as to when this will get completed?
Regards,
Rakesh RA
Please sign in to leave a comment.
Comments
2 comments