Re: [HACKERS] Refreshing subscription relation state inside atransaction block

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