Hi,
The LR Subscription has an option disable_on_error that allows the user
to define the exception behaviour in case of an error during
replication: Postgres can disable the subscription or let it retry the
operation later. It seems ok for the subscription as a whole.
Since the introduction of 'ADD/DROP table' into the ALTER PUBLICATION
command, we have an option to sync/resync some table - it may be useful
in case of row filter changed or to ensure we have correct data if
conflict stats has detected potential issues.
So, when executing REFRESH PUBLICATION or even performing the initial
synchronisation of dozens of tables, Postgres may stop the whole process
if a table has synchronisation issues - it may be a constraint, or we
forget to truncate a specific table on the subscriber and get a conflict.
So, for the sake of not disabling the whole subscription that may be
replicating a massive database and not interrupting the synchronisation
process, it makes sense to introduce a parameter, like reloption, that
could override the current exception behaviour.
For example, exception_behaviour can be 'disable', 'retry', or 'skip'.
The last value allows skipping errors during a table copy, checking sync
statuses later, fixing issues and repeating the process for problematic
tables.
In terms of SQL, it may look like the following:
ALTER SUBSCRIPTION mysub
REFRESH PUBLICATION (WITH exception_behaviour = ‘skip’);
Does it make sense?
--
regards, Andrei Lepikhov,
pgEdge
