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.
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
