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
subscriptionrefresh, the worker could be left orphaned. To avoid that, explicitly stop the worker when the
pg_subscription_relentry 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