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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to