Re: Add into REFRESH PUBLICATION parameter exception_behaviour

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

Additionally, automation scripts may depend on subscription statistics,
particularly 'sync_seq_error_count' and 'sync_table_error_count'. I was
using an older Postgres version and did not realise that newer versions
now provide clear indicators when synchronisation issues occur.

--
regards, Andrei Lepikhov,
pgEdge