> On Jun 19, 2021, at 7:44 AM, Mark Dilger <mark.dil...@enterprisedb.com> wrote:
>
> Wouldn't the user rather skip just the problematic rows? I understand that
> on the subscriber side it is difficult to do so, but if you are going to
> implement this sort of thing, it makes more sense to allow the user to filter
> out data that is problematic rather than filtering out xids that are
> problematic, and the filter shouldn't just be an in-or-out filter, but rather
> a mapping function that can redirect the data someplace else or rewrite it
> before inserting or change the pre-existing conflicting data prior to
> applying the problematic data or whatever.
Thinking about this some more, it seems my patch already sets the stage for
this sort of thing.
We could extend the concept of triggers to something like ErrorTriggers that
could be associated with subscriptions. I already have the code catching
errors for subscriptions where disable_on_error is true. We could use that
same code path for subscriptions that have one or more BEFORE or AFTER
ErrorTriggers defined. We could pass the trigger all the error context
information along with the row and subscription information, and allow the
trigger to either modify the data being replicated or make modifications to the
table being changed. I think having support for both BEFORE and AFTER would be
important, as a common design pattern might be to move aside the conflicting
rows in the BEFORE trigger, then reconcile and merge them back into the table
in the AFTER trigger. If the xid still cannot be replicated after one attempt
using the triggers, the second attempt to disable the subscription instead.
There are a lot of details to consider, but to my mind this idea is much more
user friendly than the idea that users should muck about with xids for
arbitrarily many conflicting transactions.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
