The fix for that will be in 10.2 (current target date: February 8th). The workaround in the meantime would be to disable parallelism, at least for the queries doing parallel index scans if you can identify them.
That sounds great, I hope that patch will fix it, I'm not quite sure it will though. Some of them have workers that are in the BtreePage state, however at least as many of the hung queries have only workers in the MessageQueuePutMessage state. Would you expect the patch to fix those as well? Or could it be something different?
However, I'm not entirely sure why you're not able to cancel these backends politely with pg_cancel_backend(). For example, the BtreePage waiter should be in ConditionVariableSleep() and should be interrupted by such a signal and error out in CHECK_FOR_INTERRUPTS().
All of them are definitely un-killable by anything other than a kill -9 that I've found so far. I have a feeling it has something to do with: https://jobs.zalando.com/tech/blog/hack-to-terminate-tcp-conn-postgres/?gh_src=4n3gxh1 but I'm not 100% sure, as I didn't set tcp settings low enough to make catching a packet all that reasonable. I'm happy to try to investigate further, I just don't quite know what that should entail. If you have things that you think would be helpful, please do let me know.
