On Thu, Feb 19, 2026 at 1:37 PM Andrei Lepikhov <lepihov@gmail.com> wrote:
>
> On 19/2/26 07:44, Amit Kapila wrote:
> > On Tue, Feb 17, 2026 at 1:39 PM Andrei Lepikhov <lepihov@gmail.com> 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.
