On 08/05/17 11:27, Masahiko Sawada wrote:
> Hi,
>
> I encountered a situation where DROP SUBSCRIPTION got stuck when
> initial table sync is in progress. In my environment, I created
> several tables with some data on publisher. I created subscription on
> subscriber and drop subscription immediately after that. It doesn't
> always happen but I often encountered it on my environment.
>
> ps -x command shows the following.
>
> 96796 ? Ss 0:00 postgres: masahiko postgres [local] DROP
> SUBSCRIPTION
> 96801 ? Ts 0:00 postgres: bgworker: logical replication
> worker for subscription 40993 waiting
> 96805 ? Ss 0:07 postgres: bgworker: logical replication
> worker for subscription 40993 sync 16418
> 96806 ? Ss 0:01 postgres: wal sender process masahiko [local] idle
> 96807 ? Ss 0:00 postgres: bgworker: logical replication
> worker for subscription 40993 sync 16421
> 96808 ? Ss 0:00 postgres: wal sender process masahiko [local] idle
>
> The DROP SUBSCRIPTION process (pid 96796) is waiting for the apply
> worker process (pid 96801) to stop while holding a lock on
> pg_subscription_rel. On the other hand the apply worker is waiting for
> acquiring a tuple lock on pg_subscription_rel needed for heap_update.
> Also table sync workers (pid 96805 and 96807) are waiting for the
> apply worker process to change their status.
>
Looks like we should kill apply before dropping dependencies.
> Also, even when DROP SUBSCRIPTION is done successfully, the table sync
> worker can be orphaned because I guess that the apply worker can exit
> before change status of table sync worker.
Well the tablesync worker should stop itself if the subscription got
removed, but of course again the dependencies are an issue, so we should
probably kill those explicitly as well.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services