On Tue, Feb 17, 2026 at 1:39 PM Andrei Lepikhov <[email protected]> wrote: > > On 17/2/26 06:11, Amit Kapila wrote: > > On Tue, Feb 17, 2026 at 9:52 AM Andrei Lepikhov <[email protected]> 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.
