Re: Add into REFRESH PUBLICATION parameter exception_behaviour

On Tue, Feb 17, 2026 at 9:52 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>
> On 17/2/26 05:07, Amit Kapila wrote:
> > On Mon, Feb 16, 2026 at 6:04 PM Andrei Lepikhov <lepihov(at)gmail(dot)com> 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.