Re: DROP SUBSCRIPTION hangs if sub is disabled in the same transaction

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> I think we are whacking things around a in circle now. First we moved
> the worker killing to the end of the transaction to make subscription
> DDL transaction-capable. Then we changed replication origin dropping to
> wait until the worker detaches. If you do both of these things at once,
> you get this circular dependency.

> We can break this in any number of ways:

> - (your patch) Kill workers right away after ALTER SUBSCRIPTION DISABLE,
> thus breaking the appearance of transactional DDL somewhat.

> - Revert to the old behavior that the replication origin dropping fails
> if it is in use. Then you would get an error instead of hanging. But
> that was previously also reported as a bug.

> - Disallow DROP SUBSCRIPTION in a transaction under certain
> circumstances, for example if a transaction has previously manipulated
> the same subscription.

> - Have DROP SUBSCRIPTION attempt to kill workers if the subscription is
> disabled (and possibly, was changed in the same transaction), which
> would address this scenario very narrowly.

ISTM the second of those (refuse to drop an in-use subscription) is
by far the least surprising behavior. However, I wonder if there aren't
race conditions involved here. What if we haven't yet committed a
DROP SUBSCRIPTION, and some new worker starts up after we look for
workers?

If there aren't variants of that that will break all four options,
it's not very obvious why not.

regards, tom lane