Check stv_inflight for query PID for redshift cancel #375
+2
−1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Matthew Peveler <[email protected]>
|
Not sure why the build suite is failing here, and I don't know enough about Ruby ecosystem or this project to know where to start. |
|
Hey @MasterOdin, thanks for the PR! Will dig into this next time I'm working with Redshift (not sure when that'll be exactly). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR modifies the cancel method for redshift to consider both
STV_INFLIGHToverSTV_RECENTSsystem tables. For some setups of Redshift, we are finding that getting the currently running query is more reliable to search theSTV_INFLIGHToverSTV_RECENTS. In these setups, the query will show up in the former table and not in the latter table until after the query has finished. I'm not totally certain why that is, but suspect it's something to do with the nature of cluster nodes, but the whole thing is opaque and I couldn't find any good concrete information on googling. A downside here is thatSTV_INFLIGHTincludes a lot less query text (100 vs 600) for some reason, so inclusion of both tables seems the best strategy. One thought would be to prepend the comment with run information (followed by a newline) to the query so that it's always at the beginning and so therefore always present before truncation.The join here shouldn't add too much additional overhead, but I don't have a heavily used Redshift cluster to verify against.