Re: Add into REFRESH PUBLICATION parameter exception_behaviour

On Tue, Feb 17, 2026 at 1:39 PM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>
> On 17/2/26 06:11, Amit Kapila wrote:
> > On Tue, Feb 17, 2026 at 9:52 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> > 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.
>
> Thanks for your answer, but I still don't get the idea.
>
> The case I am talking about is the following:
> In the absence of DDL propagation, it is a good palliative to DROP a
> table from publication, perform the necessary ALTER TABLEs on both
> sides, and ADD the table back to the publication.
>
> I only proposed that if the REFRESH PUBLICATION that re-introduced such
> a table fails, complain and remove it from the subscription, as if you
> had never executed the 'REFRESH PUBLICATION' command. Where is the
> inconsistency?
>

The key point is that the apply worker will continue even when the
table_sync worker has failed and skipped the relation from syncing.
Consider an example, where the user adds two tables t1_pk, t1_fk to
the publication and then performs REFRESH. In this case, further
consider, the application maintains the primary/foreign key relation
between these two tables which means the app will delete rows from
both pk and fk tables.

In such a situation, say when REFRESH command is executed and table
sync for t1_fk failed and we mark that table status as FAILED, then
the future replication will perform operations only on t_pk table even
though the same transaction has delete on both t1_pk and t_fk tables.
This is because we don't apply operations on a table for which initial
sync is not finished yet which will be true for t_fk.

--
With Regards,
Amit Kapila.