smacker commented on issue #8139: [sqllab] add retries for stop_query URL: https://github.com/apache/incubator-superset/pull/8139#issuecomment-526556144 @villebro nope. This change handles errors on superset side (main DB with superset's state). While #7611 interacts with data source connections. Let me give an example: 1. You keep your superset state (including queries) in postgresql 1. You have _huge_ MySQL DB which you use to generate data for charts and you query it using SQLLab in async mode 1. Your query makes a very expensive calculation like joining several tables with billions of rows without proper `where` statement (maybe by a mistake) 1. You realize the query is taking too long or it's just wrong and you stop it 1. Status of the query is changed in postgresql and UI works correctly. But celery job is still running in the background because the job itself doesn't have any "cancel" method except `SQLLAB_TIMEOUT`. The only place where the check for stop happens is [between queries](https://github.com/apache/incubator-superset/blob/7595d9e5fdb4e9614b6d3c812a7f26282550ff01/superset/sql_lab.py#L331). So as long as the query already started on MySQL side, it will be consuming resources on mysql server while you don't need the result of the query anymore 1. #7611 adds a hook to say to MySQL "I don't need this query anymore, please stop it". You can reproduce it by running a _long_ query, pressing stop in UI and then checking `SHOW PROCESSLIST` on your DB server. P.S. I used MySQL as an example, it would work the same for any other data source
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
