On Tue, Feb 17, 2026 at 9:52 AM Andrei Lepikhov <[email protected]> wrote: > > On 17/2/26 05:07, Amit Kapila wrote: > > On Mon, Feb 16, 2026 at 6:04 PM Andrei Lepikhov <[email protected]> wrote: > >> 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. > Hmm, in my mind, there should be a FAIL table state introduced to let > users know that a specific table has not been synchronised, and they > need to check and repeat a smaller part of the job. > Or do you mean that a synchronising table might already contain some > data, and that it is impossible to undo the sync and repeat it? >
If we introduce a new state like FAIL for a table, then in that state apply_worker should skip the new updates for that table (see should_apply_changes_for_rel()) till the copy is successful. So, all other changes in future transactions will keep getting applied except for tables that have failed status. I think this could lead to inconsistency while replicating data. -- With Regards, Amit Kapila.
