Mysql: Does context cancellation cancel the underlying query?

Created on 5 Jan 2018 · 6Comments · Source: go-sql-driver/mysql

ctx, cancel := context.WithCancel(context.Background())

// Cancel 5 seconds in.
go func() {
    time.Sleep(time.Second * 5)
    cancel()
}()

// This query should take 10 seconds to return.
rows, err := dbt.db.QueryContext(ctx, "SELECT v, SLEEP(10) FROM test LIMIT 1")
fmt.Println(rows, err)

After reading https://github.com/go-sql-driver/mysql/issues/496 and https://github.com/go-sql-driver/mysql/pull/608, I was under the impression that in the above example, the underlying query would get canceled mid-execution, but that doesn't seem to be the case. It still takes 10 seconds to return (and the query shows in MySQL process list), albeit with the error sql: Rows are closed. Does this mean that the driver isn't actually able to cancel the underlying query running on the server?

Source

knadh

Most helpful comment

Are there any plans on fixing that TODO?

arthurnn on 8 Mar 2018

👍4

All 6 comments

Hi, I'm the author of #608.

Does this mean that the driver isn't actually able to cancel the underlying query running on the server?

Yes, my implement doesn't kill the query running on the server.
It is still on TODO status.

https://github.com/go-sql-driver/mysql/blob/9181e3a86a19bacd63e68d43ae8b7b36320d8092/driver_go18_test.go#L270

shogo82148 on 6 Jan 2018

FYI, you can limit query execution time via hint.
https://dev.mysql.com/doc/refman/5.7/en/optimizer-hints.html#optimizer-hints-execution-time

methane on 6 Jan 2018

@shogo82148 @methane Thanks.

knadh on 6 Jan 2018

Are there any plans on fixing that TODO?

arthurnn on 8 Mar 2018

👍4

Are there any plans on fixing that TODO?

https://github.com/go-sql-driver/mysql/pull/791

Looks like it is in a milestone btw. For others adding circuit breaking to services and find that queries persist in mysql, you may want to watch and react to these issues so the maintainers know there is interest.

Most of my peers expected this to work because they were more familiar with postgres where such workflows are known to work, are more easy to implement / are supported by the query session natively without making more connections.

For now I am documenting in my org that mysql is less friendly here and effective support for such a feature would warrant mysql server changing their connection interface.

A work around would be nice since we have so much using mysql at the moment. :-)