On 08/05/17 01:17, Jeff Janes wrote:
> After dropping a subscription, it says it succeeded and that it dropped
> the slot on the publisher.
>
> But the publisher still has the slot, and a full-tilt process described
> by ps as
>
> postgres: wal sender process jjanes [local] idle in transaction
>
> Strace shows that this process is doing nothing but opening, reading,
> lseek, and closing from pg_wal, and calling sbrk. It never sends anything.
>
> This is not how it should work, correct?
>
No, and I don't see how this happens though, we only report success if
the publisher side said that DROP_REPLICATION_SLOT succeeded. So far I
don't see anything in source that would explain this. I will need to
reproduce it first to see what's happening (wasn't able to do that yet,
but it might just need more time since you say it does no happen always).
>
> The subscribing server's logs shows:
>
> 21270 2017-05-07 16:04:16.517 PDT LOG: process 21270 still waiting for
> AccessShareLock on relation 6100 of database 0 after 1000.051 ms
> 21270 2017-05-07 16:04:16.517 PDT DETAIL: Process holding the lock:
> 25493. Wait queue: 21270.
> 21270 2017-05-07 16:04:16.520 PDT LOG: process 21270 acquired
> AccessShareLock on relation 6100 of database 0 after 1003.608 ms
> 25493 DROP SUBSCRIPTION 2017-05-07 16:04:16.520 PDT LOG: duration:
> 1005.176 ms CPU: user: 0.00 s, system: 0.00 s, elapsed: 1.00 s
> statement: drop subscription foobar ;
>
Yeah that's normal because DropSubscription holds exclusive lock on
pg_subscription. I am guessing 21270 is the logical replication launcher?
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services