Re: Refreshing subscription relation state inside a transaction 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 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