On Mon, Feb 16, 2026 at 6:04 PM Andrei Lepikhov <[email protected]> wrote: > > 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’); >
It will lead to skipping all future changes to that table by apply worker as we skip applying till the table is in READY state. So, all changes for transactions will get applied but the ones where we skipped copy which could lead to inconsistency. I think the better way to allow skip copying of initial data for particular tables is to someway provision copy_data = off for a set of tables. -- With Regards, Amit Kapila.
