On 6/15/17 02:41, Petr Jelinek wrote: > Hmm, forcibly stopping currently running table sync is not what was > intended, I'll have to look into it. We should not be forcibly stopping > anything except the main apply worker during drop subscription (and we > do that only because we can't drop the remote replication slot otherwise).
The change being complained about was specifically to address the problem described in the commit message: Stop table sync workers when subscription relation entry is removed When a table sync worker is in waiting state and the subscription table entry is removed because of a concurrent subscription refresh, the worker could be left orphaned. To avoid that, explicitly stop the worker when the pg_subscription_rel entry is removed. Maybe that wasn't the best solution. Alternatively, the tablesync worker has to check itself whether the subscription relation entry has disappeared, or we need a post-commit check to remove orphaned workers. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers