This repository was archived by the owner on Jan 28, 2021. It is now read-only.
Do not cancel context for async queries on success #859
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #857.
The code in #806 added a context cancel call when the query handle finishes,
go-mysql-server/server/handler.go
Line 117 in 68b087c
For an async index creation the driver is called in a goroutine
go-mysql-server/sql/plan/create_index.go
Line 173 in 68b087c
And when the driver went to do the actual index creation in that goroutine, the query had already exited, and the context was cancelled
go-mysql-server/sql/index/pilosa/driver.go
Line 419 in 68b087c
The first option discussed in slack (private link) was to change the context of the
createIndex
function linked above with actx.WithContext(context.Background())
, if the call was made in a goroutine.This removes the original context cancellation, which fixes the problem, but it also prevents from doing a
KILL QUERY
of the async task afterwards. This would be a regression over the latest stable gitbase release.The code I propose in this PR instead removes the deferred context cancellation in the handler if the query is async. It feels like the code is kind of mixing responsibilities, making the Handler aware of details about the query that should be handled by the Engine. But this was the cleanest approach I could think of.
I am still trying to figure out how this could be tested, any suggestion would be welcome.