On Thu, Feb 19, 2026 at 1:37 PM Andrei Lepikhov <[email protected]> wrote: > > On 19/2/26 07:44, Amit Kapila wrote: > > On Tue, Feb 17, 2026 at 1:39 PM Andrei Lepikhov <[email protected]> wrote: > >> ... > >> 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? > > ... > > 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. > Thank you for clarifying. > > A proper 'soft' exception should revert all changes made by REFRESH > PUBLICATION on the subscriber's side. However, AlterSubscription_refresh > updates and commits the publication's state in pg_catalog before > synchronisation begins in the apply worker. Implementing a full revert > would require significant redesign and may be more appropriate for > enterprise solutions seeking this level of functionality. >
Right, and additional challenge would be to track all the background work (both by apply and successful tablesync workers) that would have happened. I guess the scenarios you are worried about can probably be handled by conflict/resolution work. -- With Regards, Amit Kapila.
